W3C home > Mailing lists > Public > public-ddwg@w3.org > August 2007

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

From: Rhys Lewis <rhys@volantis.com>
Date: Wed, 1 Aug 2007 06:13:08 -0700 (PDT)
To: <jmcf@tid.es>
Cc: <public-ddwg@w3.org>
Message-ID: <008001c7d43e$04f340a0$78a6f40a@volantisuk>

Hi Jose,

I think we are talking past each other.

The point is that the representation of the key is opaque. It's only the
REFERENCE to the key that we are discussing. I agree that the key may be
complex and have structure. DD should say nothing at all about the key,
only the reference that code has to use to reference it in an API call.
The key itself should never be passed to a caller of the API.

Let’s see if a hypothetical example helps explain what I mean. Suppose I
make a call to a DDR to identify a context from a set of http headers. It
might be something like:

contextKeyRef = getMeAContext(LotsOfHttpHeaders[]);

Ok, the DDR uses the headers to identify the context, and creates a
context key. It puts this in an array which it maintains internally. Lets
say it’s the 42nd context it's been asked to identify. It puts the key in
entry 42 in its internal array, and returns a value of 42 as the result of
the call. So at this point, contextKeyRef contains the value 42.

Later I make a call to get a property

displayBitsPerPixel = getMeAProperty(contextKeyRef,
"displayBitsPerPixel");

Now the DDR uses the value 42 in contextKeyRef, locates the context key in
its internal array, and performs the lookup.

The key itself is never exposed outside the DDR so we don't have to have a
data type for it. We only need a datatype for the reference. Here, I'm
using an integer.

Now, a simple index into an array might not be appropriate, and we might
want a different mechanism depending on the programming language.
Regardless of the actual implementation, the important point is that only
an opaque reference is passed back to the caller of the DDR. That
reference can be a simple datatype like an integer.

Does that clarify what I'm proposing?

Cheers
Rhys



-----Original Message-----
From: jmcf@tid.es [mailto:jmcf@tid.es]
Sent: 01 August 2007 10:36
To: Rhys Lewis
Cc: public-ddwg@w3.org
Subject: Re: ACTION-58 Look into issues surrounding the use of the 'any'
type in the IDL

Hi,

Another issue with integers might be flexibility. Perhaps a DDR would like
to use characters to represent the context key. For example, one trivial
context key is the concatenation of all the HTTP headers received ... I
would prefer a string in order to be as flexible as possible

Thanks and Best Regards

Rhys Lewis escribió:
> Thanks Jose, that makes perfect sense!
>
> On scalability, a 32 bit integer would give something like 4 billion
> possible concurrent context key values. Since these only have to be
> unique for a particular session between caller and repository, it's
> probably enough :)
>
> Even an automatic content adaptation engine is unlikely to need to
> reference more than a few thousand distinct contexts concurrently.
>
> Cheers, and thanks again for the explanation.
>
> Rhys
>
> -----Original Message-----
> From: jmcf@tid.es [mailto:jmcf@tid.es]
> Sent: 01 August 2007 08:40
> To: Rhys Lewis
> Cc: public-ddwg@w3.org
> Subject: Re: ACTION-58 Look into issues surrounding the use of the 'any'
> type in the IDL
>
> Hi,
>
> My action was related to investigate the any issue, although I have
> mixed it with the context key representation issue. It's my fault. So
> first of all if we decide to use the any type then my previous e-mail
> applies and explains all the issues we would need to take into account.
>
> With respect to the context key issue I understand your point. It
> sounds good to me thinking about the context key as a file handle.
> However, I would not use integer bacause doing that you may end end up
> having scalability problems, perhaps it could be better to represent
> the context key as a string.
>
> Best Regards
>
>
>
>
>
Received on Wednesday, 1 August 2007 13:13:24 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:00:14 UTC