Separate features or not? API for Media Resources 1.0

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

> 
> 
> 
> 
>