[API] Two comments about the DDR API document

Hello everyone,

Here I come with two comments in order to start the discussion about the DDR API document (Editor's Draft version 1b sent by Jo [1]) so we all can make it evolve.

First comment (IdentifyBy* functions):
-------------

There are two functions in the draft called IdentifyByUAString and IdentifyByHTTPHeaders and there as been an unresolved discussion about whether both or them are necessary or not. But I think that there is a need for a more general function, taking into account that we want the DDR API to focus on the Web (we are working in a W3C WG) but never closing doors for its extension to other content adaptation.

For instance, and following the description format for DDR functions used in [1], we might propose a function like:

--------------------------------------------------------------
IdentifyByString (alternative better names are welcome!)

Inputs

    String (string)

      A string containing information allowing the identification of the browser and/or device. Its format is specified by input parameter "Format".

    Format (unsigned integer? String?)
	
	A unsigned integer (for me, but it is obviously open to discussion) declaring the format in which information is expressed in input parameter "String".

    Single (boolean - default False)

        Return only the best match if true, otherwise return a set of matches

Outputs

    Success

        Values: Exact Match Found, Found, Not Found

    Context Key

        A Context Key opaquely referencing various component types and their alternatives

Exceptions
	tbd
 
--------------------------------------------------------------

An example:

   idString = "User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.8.1.7) Gecko/20070914 Firefox/2.0.0.7\r\nAccept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5\r\n....";

   [success, contextKey] = IdentifyByString(idString, HTTP_HEADERS, false); 

Where HTTP_HEADERS might be a symbolic constant representing the unsigned integer value of 1.

This would be the same as using IdentifyByHTTPHeaders. In fact, IdentifyByHTTPHeaders would now be a convenience function.

Another example would be a string including RTSP headers (if I want to cover content adaptation for media streaming). So the idString would have a sequence of RTSP headers in a format very similar to HTTP 1.1, but with the input parameter "Format" with a value of 2 for instance (expressed maybe by the corresponding RTSP_HEADERS symbolic constant).

One more example: we might try to identify, as said several times within this group, by IMEI. Just use a new value for "Format" (3, for instance), write the IMEI in the String input parameter... et voilá.

DDWG would only set some values for the "Format" input parameter (maybe only one is needed: for HTTP Headers) but would let the door open for extensions of the DDR API to other organizations, companies, etc. willing to deal with RTSP, IMEIs and whatever.

What do you think about this approach?

While you answer, I shall cover my second comment.

Second comment (What is an HTTP Header? O:-) ):
--------------

When we are talking about HTTP headers, being a W3C working group, we should only expect that. I mean... Should we support proprietary headers, just like HTTP_UA_PIXELS and many others?

If non standard HTTP headers are included, being a purist, anything out of the HTTP spec should make (for example) IdentifyByHTTPHeaders raise an exception.

I was just thinking out loud. I'd personally allow those HTTP "extensions", but I fear that we go on as the developers we are, and afterwards someone blames our API for not following [2]. There is a good excuse to avoid this issue: leave that subject open to implementations. Anyway, it might be good to make a comment anywhere in the DDR API doc.

Best regards,

Nacho

[1] http://www.w3.org/2005/MWI/DDWG/drafts/api/070831 
[2] http://www.w3.org/Protocols/rfc2616/rfc2616.html

Received on Wednesday, 10 October 2007 21:58:54 UTC