Re: Separate features or not? API for Media Resources 1.0

Agreed, I am available next Tuesday. How about Daniel and Thierry?



On 25 Sep 2012, at 16:57, Florian Stegmaier wrote:

> Dear all,
> 
> due to this comments of TBL, we should immediately schedule a teleconf. Those comments clearly address two major issues:
> 
> 1) there is a need to rephrase our definitions of client- and server-side, since they are misleading / not clear enough.
> 2) we need to work on implementation. Here, a intermediate prototype could serve as the "missing link" and maybe also underline our understanding of client as well as server side.
> 
> Unfortunately, i have no resources in near future to work on 2. Any comments on this issues?
> 
> Best,
> Florian
> _____________________________
> Dipl. Inf. Florian Stegmaier
> Chair of Distributed Information Systems
> University of Passau
> Innstr. 43
> 94032 Passau
> 
> Room 248 ITZ
> 
> Tel.: +49 851 509 3063
> Fax: +49 851 509 3062
> 
> http://twitter.com/fstegmai
> http://www.mendeley.com/profiles/florian-stegmaier/
> _____________________________
> 
> Anfang der weitergeleiteten Nachricht:
> 
>> Umgeleitet von: public-media-annotation@w3.org
>> Von: Tim Berners-Lee <timbl@w3.org>
>> Betreff: Separate features or not? API for Media Resources 1.0
>> Datum: 25. September 2012 16:11:48 MESZ
>> An: Joakim Söderberg <joakim.soderberg@ericsson.com>
>> Kopie: public-media-annotation@w3.org <public-media-annotation@w3.org>, TAG List <www-tag@w3.org>
>> 
>> 
>> I'm Ccing www-tag as there is a general question about what
>> people mean by features and what we should aim for in terms
>> of interop.
>> 
>> The question in debate is whether Media Resources is ready to 
>> come out of CR, without two implementations of each version
>> of its API, sync and async.
>> 
>>> From: Joakim Söderberg <joakim.soderberg@ericsson.com>
>>> To: Philippe Le Hegaret <plh@w3.org>
>>> Cc: public-media-annotation@w3.org <public-media-annotation@w3.org>
>>> Subject: API for Media Resources 1.0
>>> Date: Mon, 27 Aug 2012 12:52:32 +0200
>>> 
>>> Dear Philippe,
>>> Here is the WG response to your questions.
>>> 
>>> a) Availability of the code:
>>> All implementations are open source projects. LMF is hosted at Github, the
>>> browser extension can be downloaded at the prototype page (the dpi includes
>>> the source files and can be extracted similar to a ZIP file). The third
>>> implementation (web service) can be downloaded at source forge.
>>> 
>>> 
>>> b) Usage of the API
>>> Find included two papers that explain the implementations. They should give
>>> the needed details for the browser extension and the server side
>>> implementation. The code pieces of the API will soon be available in the LMF
>>> branch at Github (maybe with the next major release). Currently it can be
>>> found here:
>>> 
>>> 
>>> https://svn.salzburgresearch.at/svn/lmf-media/
>>> 
>>> 
>>> This project needs the complete LMF as dependency. That´s why it seems to be
>>> a little bit "tiny".
>>> 
>>> 
>>> c) number of implementations
>>> This was discussed, that we do not see the sync and the async mode as
>>> separate features.
>> 
>> Let me understand what your mean by that.
>> 
>> You can't have your cake and eat it.
>> If they are not separate features, then every implementation implements both.
>> A client can chose which or a combination of them which it uses, and works
>> in either case.
>> 
>> If servers sometimes implement one without the other, then of course
>> interop is much reduced.   (Unless every client is written to work with either).
>> You have really two smaller specs which may 
>> or may not be each implemented by various servers.
>> You have to effectively show that each spec contributes usefully
>> to the interop in the world, and the typical way is to show at least two
>> interoperable implementations.
>> 
>> 
>> 
>>> We have the following paragraph in the status section of
>>> the API doc: “The API is designed for both client- and server side
>>> implementations.
>> 
>> Not clear just from that text what it means.  To me, client-side means it
>> runs e.g. within the page or an extension, 
>> and server side means it runs within a server.
>> In either case we are talking about local calls, not remote procedure call.
>> 
>> Client-server implementations  are a third category, and and as they involve
>> network communication, in an event-driven callback environment,
>> making them async is important, so that calling code does not hang.
>> 
>>> Depending on whether the API is implemented in a user agent
>>> or plugin, or as a web service, different communication patterns are more
>>> appropriate.
>> 
>> "Communication patterns"?  API design or networ protocol?
>> 
>>> In the client side case, asynchronous access is typically
>>> preferred, while synchronous access is more appropriate for a web service.
>> 
>> This is the reverse of what I would have thought, assuming client-side
>> means local to the client, and 'web service' means a remote call
>> over the network. I assume the words are being used differently, 
>> "client-side" meaning client-server, and "web service" meaning server-local maybe?
>> 
>>> Thus the two version of the interface are not considered distinct features
>>> but different modes of access for the different use cases.”
>> 
>> 
>> Different modes of access to the same implementation?
>> No, I gather not -- these are two quite incompatible APIs.
>> Not because they don't look similar in their parameters,
>> but because because if you need one and you have the
>> other, your code doesn't work.
>> 
>> Interop means basically that if you have two products, one
>> says on its box "Needs x" and the other says on its box
>> "Provides x" and you install both, things work.
>> 
>> Currently, this works with x as MR1.0-async or MR1.0-sync
>> but not x as MR1.0.
>> 
>> In this case, you have to distinguish on the box whether
>> it is sync or async. If that is the case, then you have to be 
>> up-front about it, the spec defines two APIs. you need to test both,
>> and ideally for each show 2 interoperable implementations.
>> 
>> Tim
>> (Not with director decision hat on, just thinkin').
>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>