RE: [Policy] identifying APIs

Hi John,

One more comment:
Probably UPnP (just local network) or UPnP-like architecture could be used to handle "WebAPI" discovery.
This could in some way help with versioning in my opinion.

Thanks,
Marcin

Marcin Hanclik
ACCESS Systems Germany GmbH
Tel: +49-208-8290-6452  |  Fax: +49-208-8290-6465
Mobile: +49-163-8290-646
E-Mail: marcin.hanclik@access-company.com

-----Original Message-----
From: public-device-apis-request@w3.org [mailto:public-device-apis-request@w3.org] On Behalf Of Marcin Hanclik
Sent: Wednesday, October 07, 2009 11:34 AM
To: John Kemp
Cc: Frederick Hirsch; W3C Device APIs and Policy WG
Subject: RE: [Policy] identifying APIs

Hi John,

Thanks for the URL and the interesting paper.
I am awaiting the section about versioning :)
This is a HOT topic ;)

I think the errors/exceptions can be unified (they basically do the same, but a bit differently).
IMHO XHR's status and JSON/XML could handle the architecture you propose.
To be architecturally clean, I think you could start with mapping WebIDL to URIs to be generic.
If that architecture is ready, it could be applied to DAP APIs.

For the representation you propose and as indicated in [1], we would need Widget URI to make it all happen.
Then we would use cross-document / cross-widget messaging or XHR (it could be irrelevant what is used).

Thanks,
Marcin

[1] http://lists.w3.org/Archives/Public/public-device-apis/2009Oct/0065.html

Marcin Hanclik
ACCESS Systems Germany GmbH
Tel: +49-208-8290-6452  |  Fax: +49-208-8290-6465
Mobile: +49-163-8290-646
E-Mail: marcin.hanclik@access-company.com

-----Original Message-----
From: John Kemp [mailto:john@jkemp.net]
Sent: Wednesday, October 07, 2009 1:52 AM
To: Marcin Hanclik
Cc: Frederick Hirsch; W3C Device APIs and Policy WG
Subject: Re: [Policy] identifying APIs

Hey Marcin,

On Oct 6, 2009, at 5:35 PM, Marcin Hanclik wrote:

> Hi John,
>
> Would it be possible for you to share [API]?

http://jkemp.net/tag/apis-on-the-web.html on my personal website.

>
> Why would we need APIs to be resources? (I know it is possible,
> but ...)

I don't think you'd need to have it be that way, but I was just
imagining what it would be like if you were to imagine a 'My Calendar'
resource, and give it a URI. If you operated an HTTP server on your
device, you could give out a URI something like (just an example) http://my-device/Calendar/today
  to get a list of calendar entries for that day.

You could also imagine calling a function - 'calendar.entries( new Date
() ) ;' to return exactly the same information - a representation of
the same resource pointed to by the URI noted above.

I'm not sure if this is useful per se, but for me it reconciles the
RESTful with the "scriptful" somewhat if you imagine that the result
of a JS call is a representation of the same resource used to fulfill
a request to a particular URI.

Cheers,

- johnk

________________________________________

Access Systems Germany GmbH
Essener Strasse 5  |  D-46047 Oberhausen
HRB 13548 Amtsgericht Duisburg
Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda

www.access-company.com

CONFIDENTIALITY NOTICE
This e-mail and any attachments hereto may contain information that is privileged or confidential, and is intended for use only by the
individual or entity to which it is addressed. Any disclosure, copying or distribution of the information by anyone else is strictly prohibited.
If you have received this document in error, please notify us promptly by responding to this e-mail. Thank you.


________________________________________

Access Systems Germany GmbH
Essener Strasse 5  |  D-46047 Oberhausen
HRB 13548 Amtsgericht Duisburg
Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda

www.access-company.com

CONFIDENTIALITY NOTICE
This e-mail and any attachments hereto may contain information that is privileged or confidential, and is intended for use only by the
individual or entity to which it is addressed. Any disclosure, copying or distribution of the information by anyone else is strictly prohibited.
If you have received this document in error, please notify us promptly by responding to this e-mail. Thank you.

Received on Wednesday, 7 October 2009 09:37:56 UTC