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 Tuesday, 28 August 2007 10:00:14 UTC