[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ws-caf] [Bug 140] New: content (URL) dereference needs explaining (or removing)
>===== Original Message From "Furniss, Peter" <Peter.Furniss@choreology.com> ===== >of course, another approach would be to remove the ContextManager >service and use ONLY >the http get, put. Since more of the http infrastructure is deployed, >that might be better. Since we're talking about options: Or the "raw" http could be removed, since an addressing implementation for the context manager could be written using http anyway, rather than WS-MD or WS-Addressing. More below: > >Peter > >> -----Original Message----- >> From: bugzilla-daemon@arjuna.com [mailto:bugzilla-daemon@arjuna.com] >> Sent: 30 June 2004 13:31 >> To: ws-caf@lists.oasis-open.org >> Subject: [ws-caf] [Bug 140] New: content (URL) dereference >> needs explaining (or removing) >> >> >> http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=140 >> >> Summary: contenSt (URL) dereference needs >> explaining (or removing) >> Product: WS-Context >> Version: 1.0 >> Platform: PC >> OS/Version: Windows 2000 >> Status: NEW >> Severity: normal >> Priority: P2 >> Component: Text and diagrams >> AssignedTo: ws-caf@lists.oasis-open.org >> ReportedBy: peter.furniss@choreology.com >> QAContact: mark.little@arjuna.com >> >> >> 0.3 offers alternative ways of dereferencing a >> context-by-reference : the >> ContextManager service described in section 3, or a "URL that >> may be dereferenced to resolve the data directly" >> >> Presumably this will usually (always ?) be an http or https url. Some >> unanswered questions are: I don't think we should restrict the protocol at all. If an implementation wants to use ftp for example, then why not? >> >> 1. is the context identifier involved in the dereference ? If >> so, how ? >> Presumably not, in which case the content uri must itself be >> an unambiguous >> identifer for the context. Should this be pointed out. Should >> there be a short >> form, meaning "use the context identifier for this" ? (it >> would be a mistake to >> force the ctx identifier to be usable as the "content URI") We would definitely need text to say that the URL must umabiguosly resolve to the context (I thought we had such text, but maybe not). The format of that URL does not need to be defined. >> >> 2. What is the type of the reply ? Are there constraints on >> the mime type (it >> should say even (or especially) if this is obvious) Yes, we definitely need to provide this. application/xml seems appropriate. >> >> 3. ContextManager getContents has various fault replies. >> Shouldn't the >> specification state exactly which http responses are equivalent. Agreed. >> >> 4. ContextManager has both getContents and putContents. Can a >> content URI be used to PUT a replacement contents in the same >> way (and subject to similar >> security, concurrency considerations if necessary) Yes, on the assumption we maintain two different ways of doing things, we definitely need make sure that the interaction patterns are identically described, where possible. >> >> 5. Is it really desirable to have two ways of doing the same thing ? I have to admit that at the moment I'm not sure. I think the http route helps some of the REST arguments that we've seen. However, does an implementation of "addressing" based on http only give the same results (i.e., if we remove the explicit http protocol and use EPRs throughout.) >> >> 6. Are referencing specifications expected/allowed to >> constrain to use only one >> form ? Let's get 5 figured out first. 6 may be moot in that case. Mark. >> >> >> >> ------- You are receiving this mail because: ------- >> You are the assignee for the bug, or are watching the assignee. >>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]