Hi Dims, > Guiding principle was that our Service Group concept is an internal > detail that should not be visible in any of the artifacts (WSDL, EPR) > or on the wire.
+1. > Let's get enough implementation experience with this > before we go the whole hog. Am not convinced that we should let it > "leak" via EPR's (as in #5). Also please see below: The issue of course is whether a string that looks like a string to the outsides is a leak .. see my comments under #4. > #1 - No one said that we should not show SG's in UI's. It's ok to do so. > #2 and #3 - We still need to do them, yes, they should work the way > you outlined it. OK cool. > #4 - is a simple matter of throwing an exception on deployment, it's > easy to change it later (depending on #5) OK let's compromise .. let's do the pattern where we keep the names flat (as in a string without colons) for now and we can throw an exception on deployment (as you propose above). If (when ;-)) this becomes a problem we'll decide how to put the SG name into the URL so we don't have to tell users to rename stuff. > #5 - ':' apprears in IPv6 (and seems non REST-ful). I agree its non RESTful .. but making it RESTful (which I'd prefer) will amount to showing the SG concept in the URLs explicitly. Its kinda neat though because then we could have SG/SN[/op_name[/message_name[/msgid]]] .. totally RESTful way to refer to everything. Definitely post 1.0 :). > Let's get some code working w/o leaking our SG's, go thru the Alpha at > least and take a checkpoint later if life becomes unbearable. +1. Sanjiva.
