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

FYI. Interesting discussion about interoperability and testing.

Felix
---------- Weitergeleitete Nachricht ----------
Von: "Tim Berners-Lee" <timbl@w3.org>
Datum: 25.09.2012 16:16
Betreff: Separate features or not? API for Media Resources 1.0
An: "Joakim Söderberg" <joakim.soderberg@ericsson.com>
Cc: "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').