W3C home > Mailing lists > Public > public-media-annotation@w3.org > February 2010

Re: API at client/server side

From: Felix Sasaki <felix.sasaki@fh-potsdam.de>
Date: Tue, 9 Feb 2010 09:04:37 +0100
Message-ID: <ba4134971002090004i318bdca3q851fdcff30500e00@mail.gmail.com>
To: "Bailer, Werner" <werner.bailer@joanneum.at>
Cc: Joakim Söderberg <joakim.soderberg@ericsson.com>, "public-media-annotation@w3.org" <public-media-annotation@w3.org>
Thanks for the explanation, Werner. I do not think that we necessarily need
to define a WSDL binding for Web IDL, but we could define

a) an additional syntax to the Web IDL syntax, which mappes easily to HTTP
query parameters, e.g. using the names of the properties like in
b) return types independent of Web IDL, but with identical content. Here we
could use jason, XML or whatever syntax people prefer.

If people agree on that path and on what syntax to chose I could make a
proposal for updating all sections of the API document with these additional



2010/2/9 Bailer, Werner <werner.bailer@joanneum.at>

> Dear Felix,
> I agree that in scenario 2 one could directly access the web service, I
> should add this as another path to the figure to make that clear.
> The reason for putting the JavaScript client API into the figure is two
> show two options how the API could be used scriptable from a user agent, but
> with the logic implemented in different places. One formal issue is the
> specification of the API of the Web service, as there is no WSDL binding for
> Web IDL.
> Best regards,
> Werner
> ________________________________
> Von: felix.sasaki@googlemail.com [felix.sasaki@googlemail.com] im Auftrag
> von Felix Sasaki [felix.sasaki@fh-potsdam.de]
> Gesendet: Montag, 08. Februar 2010 22:51
> An: Bailer, Werner
> Cc: Joakim Söderberg; public-media-annotation@w3.org
> Betreff: Re: API at client/server side
> I agree with option 1. For option 2, I don't understand why the
> implementation as a web service requires a user agent and a java script
> library to call a service. Shouldn't that be any API in any programming
> languages that knows how to work with the Media Resource API? I am thinking
> about a scenario like metadata harvester who does the harvesting without any
> relation to a user interface, and wants to talk to the Media Resource API.
> Appologies in advance if I missed some bits of the discussion. Except that
> (minor) bit, I think the figure is very good.
> Best,
> Felix
> 2010/2/7 Bailer, Werner <werner.bailer@joanneum.at<mailto:
> werner.bailer@joanneum.at>>
> Dear all,
> if the options outlined in the figure are agreed, I can write propose some
> initial text (based on the short discussion on the list after I sent the
> figure). Probably Chris, Wonsuk and others have things to add from their
> experience.
> Best regards,
> Werner
> ________________________________________
> Von: public-media-annotation-request@w3.org<mailto:
> public-media-annotation-request@w3.org> [
> public-media-annotation-request@w3.org<mailto:
> public-media-annotation-request@w3.org>] im Auftrag von Joakim Söderberg [
> joakim.soderberg@ericsson.com<mailto:joakim.soderberg@ericsson.com>]
> Gesendet: Sonntag, 07. Februar 2010 16:28
> An: public-media-annotation@w3.org<mailto:public-media-annotation@w3.org>
>  Betreff: API at client/server side
> Dear all,
> Do you agree with me to include a section in the API doc about
> implementation issues? I think it would be helpful for the test
> implementers, and it can serve as an initial effort on a Primer doc.
> If so do we have volunteers to write this section? Werner has already drawn
> a nice figure (included).
> Regards
> Joakim
Received on Tuesday, 9 February 2010 08:05:10 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:17:36 UTC