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

Actually, the most flexible handle type would be a dedicated handle type (neither int nor string), which brings us back to the ANY issue. If the ANY issue can be resolved, I'd prefer to create an opaque type to represent handles.

Obviously, the context key to which the handle refers must remain an opaque object given the fact that no agreement on representation of context can be achieved (as it's use-case dependent).

---Rotan.

-----Original Message-----
From: public-ddwg-request@w3.org [mailto:public-ddwg-request@w3.org] On Behalf Of José Manuel Cantera Fonseca
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 09:51:12 UTC