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)

["Furniss, Peter" <Peter.Furniss@choreology.com>]

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
> 
> 
>