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

I should be available as well.

  pa

On Tue, Sep 25, 2012 at 10:21 PM, Joakim Söderberg <
joakim.soderberg@ericsson.com> wrote:

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