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

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').
> 
>> 
>> 
>> 
>> 
>>