[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ws-caf] three forms of context (was RE: [ws-caf] [Bug 135] New: participating-services list needs to have defined semantics and modification mechanisms or be removed)
Eric, Could you outline what this might do - I'm not clear of the functional scope you envisage. If it's just the participating-services-list thing, the other message thread (Slightly-restful participating-services-list facility) has some suggestions (the spec outline is in 13 and 14 of that). If it's wider than that, there might be some interesting implications. Peter > -----Original Message----- > From: Newcomer, Eric [mailto:Eric.Newcomer@iona.com] > Sent: 27 June 2004 22:39 > To: Mark Little; Furniss, Peter; ws-caf@lists.oasis-open.org > Subject: RE: [ws-caf] three forms of context (was RE: > [ws-caf] [Bug 135] New: participating-services list needs to > have defined semantics and modification mechanisms or be removed) > > > Yes, I'd like to propose an initial discussion on the idea > for a very lightweight "rerencing spec" separately before we > get into how it might (if at all, since it might not even end > up being a good idea) relate to anything else. > > -----Original Message----- > From: Mark Little [mailto:Mark.Little@arjuna.com] > Sent: Sunday, June 27, 2004 2:16 PM > To: Furniss, Peter; ws-caf@lists.oasis-open.org > Subject: RE: [ws-caf] three forms of context (was RE: > [ws-caf] [Bug 135] > New: participating-services list needs to have defined > semantics and modification mechanisms or be removed) > > > Peter, I agree that we need to discuss this. In that light, > can you expand on > why you think having multiple protocols inhibits > interoperability? Ignore the > mandated versus optional argument at the moment, and let's > assume all are > mandated to be a compliant implementation (we can relax > restrictions later). > > Mark. > > >===== Original Message From "Furniss, Peter" > ><Peter.Furniss@choreology.com> > ===== > >In considering the slightly-RESTful participating-services facility > >(see other message) I realised we have now got three > different forms of > >context: > > propagated by value > > propagated by reference, dereferenced by ContextManager > getContents > > propagated by reference, dereferenced by http get > > > >As the p-s discussion I think shows, those have distinctly different > >implications of implementations. Particularly for the last two, is a > >ws-context implementation required to handle both ? Do we > actually want > >all this "flexibility" - it looks nice, but in fact it inhibits > >interoperablity and makes it more difficult to get things to work > >together. You can't just mix-and-match, because they won't match. > > > >Of course, a referencing specification can nail things down > (as in the > >p-s facility), but then it becomes doubtful how much ref specs that > >choose different options are actually benefitting from the "common" > >base. We don't want ws-context to end up like OSI Session, which was > >pretty much two different protocols munged together in the same > >document, but with different app protocols choosing different > >"functional units" to get back to the session protocol they were > >actually using. No-one benefitted from that - implementors, users, > >other standardisers (not even the techno-politicians who had > insisted > >on it originally, as far as I know) > > > >A common base assists implementation if the implementor of a higher > >spec can use the implementation of the lower. But if the > lower is full > >of options that doesn't actually help - its quicker to implement the > >specific as part of the higher than make an all-possibilities lower > >first and choose from it. > > > >On the specific, I think we should drop one of the two dereferencing > >mechanisms. I could put this in as an issue, but lets chase > it round a > >bit first. > > > >Peter > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]