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

Hi Tim, 
Thank you for the valuable input. 
First of all we will clarify the definitions of client-only and client-server, but the big question is of course how to deal with the two modes.
The WG will discuss this in the coming weeks. At this point I would also like to reach out to the TAG team for advice if you had a similar problem?


/JS
 who has followed our work and has 

On 25 Sep 2012, at 16:11, Tim Berners-Lee wrote:

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