Re: [mawg] AW: [mawg] Re: ACTION-177: API at client/server side

On Thu, Nov 12, 2009 at 8:20 AM, Pierre-Antoine
<pierre-antoine.champin@liris.cnrs.fr> wrote:
> Le 11/11/2009 11:29, Bailer, Werner a écrit :
>> Dear Pierre-Antoine,
>>
>> we had a discussion about this issue at the F2F, triggered by comments from Doug Schepers. The arguments for having one function are
>>
>> - browser vendors only need to implement one function to support the API
>
> well, ok but that function embeds the complexity of all the small ones
> they would have to implement in the other scenario, so...


It's not about the complexity of implementation work that the browser
vendors have to do - that is almost the same no matter what API we
chose.

It's about the number of functions that gets added to the javascript
API and exposed in HTML and therefore the number of functions that
have to be learnt by a Web developer / managed by interfaces etc.

You can "hide" the complexity and specifics of every field in a
special struct and identify the dimensions through consts.

For example, check out this ID3 tag library:
http://id3lib.sourceforge.net/api/index.html

It has one function to extract all all id3 tags from a file: a "Link"
method in the  ID3_Tag class

   ID3_Tag myTag("song.mp3");
   myTag.Link("song.mp3");

Then you can use classic programming language constructs that are also
in javascript and other languages to iterate through them.

The types of fields you can extract are listed as consts:
http://id3lib.sourceforge.net/api/globals_8h.html#a219 .

There is one function to access them: a GetField function that takes
the const as a parameter and returns a struct dependent on the const.

  ID3_Field* myField = myFrame->GetField(ID3FN_TEXT);


That's basically all.

You can always extend the interface by bridging some functionality,
e.g. to directly get at the title. But it's not strictly necessary in
the API.

Hope this helps clarify.

Cheers,
Silvia.

Received on Wednesday, 11 November 2009 22:00:59 UTC