RE: ACTION-58 Look into issues surrounding the use of the 'any' type in the IDL

How about this

The context key is an opaque reference to a structure the details of which are determined on a per "instance type" basis. It is used in some API calls to provide part of the query information.

Depending on the implementation type, the context key may opaquely hold session information. Whether or not it does so is a local matter to the implementation, however, users of the API should handle responses from API calls containing a status of CONTEXT_KEY_NO_LONGER_VALID. To continue to use the API a new context key should be generated, implying that applications SHOULD maintain a copy of the original information with which the context key was generated to deal with this eventuality. 

Jo

> -----Original Message-----
> From: public-ddwg-request@w3.org [mailto:public-ddwg-request@w3.org] On
> Behalf Of Rotan Hanrahan
> Sent: 28 August 2007 11:00
> To: public-ddwg@w3.org
> Subject: RE: ACTION-58 Look into issues surrounding the use of the 'any'
> type in the IDL
> 
> 
> Hi all,
> 
> Either the context key exists as part of a session, or it is accompanied
> by some kind of expiry information (i.e. "period of validity"), because
> practical experience shows that contextual information can change, as can
> the mechanisms of device recognition. For example, identifying a context
> based on a pattern within a User Agent string may need to be adjusted if
> the pattern needs refinement due to the introduction of a new device on
> the market that causes an ambiguity. This happens all the time :(
> 
> While it may sound good to some for the context key to be used in a purely
> RESTful manner, the reality is that it's impractical. I agree with what is
> being said in this thread, and I like all the ideas (sessions, start/stop
> boundaries, expiry...). So long as the period of validity for the context
> key is bounded (either by a session, an implicit or explicit expiry, an
> open/close, acquire/release or similar mechanism) then I think the model
> will work.
> 
> Assuming we're agreed on much of this, I think it should be reflected in
> the API specification, so we should have a section to describe the
> deployment intentions for the context key.
> 
> ---Rotan.
> 
> -----Original Message-----
> From: public-ddwg-request@w3.org [mailto:public-ddwg-request@w3.org] On
> Behalf Of Rhys Lewis
> Sent: 28 August 2007 10:17
> To: 'Jo Rabin'; public-ddwg@w3.org
> Subject: RE: ACTION-58 Look into issues surrounding the use of the 'any'
> type in the IDL
> 
> 
> Hello Jo,
> 
> Agreed. And you are right that the persistence question is important.
> Web-based 'sessions' are typically bounded by some predefined time period.
> If the session remains unused for more than this period, it is closed.
> 
> Maybe it's helpful to think about connecting to and disconnecting from a
> repository rather than explicitly defining a session. Even for local
> bindings, connection and disconnection can be important events since they
> often mark the time when resources are allocated and freed. For a
> file-based implementation, for example, connection might be the time when
> the file is opened.
> 
> Even if connection can be made implicit, making disconnection explicit is
> useful because it allows resources like open files and database
> connections to be released.
> 
> Best wishes
> Rhys
> 
> -----Original Message-----
> From: Jo Rabin [mailto:jrabin@mtld.mobi]
> Sent: 28 August 2007 08:59
> To: Rhys Lewis; public-ddwg@w3.org
> Subject: RE: ACTION-58 Look into issues surrounding the use of the 'any'
> type in the IDL
> 
> As ever, Rhys, it looks as though we substantially agree.
> 
> I think we could look more closely at the persistence question. I'm not
> sure of how much of a burden it is to insist on a restful implementation,
> even in the presence of dynamically computed keys. The key must be
> persistent for _some_ period in the context of a session, and presumably
> during the session the data can be updated and so an implementation needs
> to find a way of allocating a key at the start of a session and make it
> stick for the duration. I suppose that a session can be arbitrarily long
> so how is that different from having a 'persistent' key?
> 
> I'd rather avoid defining sessions, especially as some implementations
> will not require it.
> 
> Jo
> 
> 
> > -----Original Message-----
> > From: Rhys Lewis [mailto:rhys@volantis.com]
> > Sent: 28 August 2007 08:32
> > To: Jo Rabin; public-ddwg@w3.org
> > Subject: RE: ACTION-58 Look into issues surrounding the use of the 'any'
> > type in the IDL
> >
> > Hello Jo,
> >
> > I think we are saying the same thing.
> >
> > By the way, I don't think I did say what you thought I said in d). A
> > key identifies a context, but doesn't encode it. In other words, I
> > can't take a context and peer inside it to get useful information.
> > What I can do is hand it back to the DDR implementation and ask it to
> peer inside for me.
> > That's all I meant when I said that users of the DDR can't infer
> > anything about the key. It's like a URI. I can use it to uniquely
> > identify a context, but I can't tell anything about the context from the
> key itself.
> > I can however hand the key to an API that can tell me about the context.
> >
> > On scope, I don't think keys can have global scope. Data in a DDR
> > changes over time and that could affect the computation of a key.
> > Computing the key on every access is potentially very expensive.
> > Sessions provide a nice compromise. It's a purely practical issue.
> >
> > Best wishes
> > Rhys
> >
> >
> > -----Original Message-----
> > From: public-ddwg-request@w3.org [mailto:public-ddwg-request@w3.org]
> > On Behalf Of Jo Rabin
> > Sent: 28 August 2007 08:20
> > To: public-ddwg@w3.org
> > Subject: RE: ACTION-58 Look into issues surrounding the use of the 'any'
> > type in the IDL
> >
> >
> >
> > My 2 Euro Cents on this as follows:
> >
> > a) I think the context key needs to be of a known standard type
> > between implementations - I am not sure I am happy with an integer,
> > I'd be happier with a string which allows more flexibility. That said,
> > I'd be equally happy with any other arbitrary length structure or
> > happier still with an opaque Object.
> > b) I don't think an instance of a context key is portable between
> > implementation types
> > c) it may be portable between instances of the same type - that's up
> > to the implementation
> > d) I'm not sure I understand when Rhys says that a context key doesn't
> > identify a context, because inter alia it seems to me that it does
> > identify aspects of a context but only to instances as discussed above
> > e) I am having difficulty with how persistent a context key needs to be.
> > When discussed in the context of a 'session', I find this difficult to
> > reconcile with the idea of the API being implemented in a RESTful way.
> >
> > Jo
> >
> >
> > > -----Original Message-----
> > > From: public-ddwg-request@w3.org [mailto:public-ddwg-request@w3.org]
> > > On Behalf Of Rhys Lewis
> > > Sent: 28 August 2007 08:00
> > > To: 'Matt Womer'
> > > Cc: 'José Manuel Cantera Fonseca'; public-ddwg@w3.org
> > > Subject: RE: ACTION-58 Look into issues surrounding the use of the
> 'any'
> > > type in the IDL
> > >
> > >
> > > Hi Matt,
> > >
> > > Yes, I think the key has to be completely opaque.
> > >
> > > I'm not sure I get the distinction between using some type of hash
> > > on an instance of a context and an  integer. As long as the user of
> > > the key can't tell what's inside it, without asking the
> > > implementation of the DDR, it doesn't really matter. Integers are
> > > just easier to hand around and are of predefined length.
> > >
> > > So, I think we are both saying the following:
> > >
> > > - The context is an implementation-specific data structure that is
> > > internal to the DDR implementation
> > > - The context key is an opaque way for a user of the DDR to refer to
> > > a particular context
> > > - Users of a DDR get a context key in response to specific operations.
> > > These include DDR operations to
> > >   identify a context from a set of HTTP headers, for example.
> > > - Users of the DDR can ask questions about the context. In doing so,
> > > they supply the appropriate context
> > >   key to the appropriate DDR API.
> > > - Users of the DDR cannot infer anything about the context directly
> > > from the value of the context key
> > >   itself. In particular, the key does NOT encode the context.
> > > - Context keys are NOT portable across different implementations of
> > > DDRs
> > >
> > > Whether the key is an integer or a hash of some kind doesn't really
> > > matter. I think in practice that integers would be simpler, but
> > > that's just an implementation detail.
> > >
> > > Does that help?
> > >
> > > Best wishes
> > > Rhys
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: Matt Womer [mailto:mdw@w3.org]
> > > Sent: 27 August 2007 17:47
> > > To: Rhys Lewis
> > > Cc: 'José Manuel Cantera Fonseca'; public-ddwg@w3.org
> > > Subject: Re: ACTION-58 Look into issues surrounding the use of the
> 'any'
> > > type in the IDL
> > >
> > > Hi Rhys, José, DDers,
> > >
> > > On Aug 1, 2007, at 3:32 AM, Rhys Lewis wrote:
> > > > If all that sounds correct, then the 'handle' for the context key
> > > > merely has to identify it within a session that a caller has with
> > > > the DDR.
> > > > So,
> > > > can't it just be an integer?
> > >
> > > Thanks for writing this up, it helped me understand where the
> > > confusion is coming from.
> > >
> > > I think of the Context Key IS the opaque handle itself.  It is a
> > > handle to the "Context", which is an implementation specific
> > > structure in and of itself.
> > >
> > > I assumed that from the name that it was a 'key' in a list/hash/map
> > > of contexts, and I think from your email that this isn't what you're
> > > thinking.  RIght?
> > >
> > > What do other folks think?
> > >
> > > -Matt Womer
> > >
> > > mdw@w3.org
> > > W3C Team -- http://www.w3.org/
> > > Mobile Web Initiative Lead Americas
> > > Team Contact: MWI DDWG, POWDER, Voice Browser
> > >
> > >
> > >
> >
> >
> 
> 
>

Received on Wednesday, 29 August 2007 15:02:41 UTC