Re: [Fwd: W3C and APIs -- request for agenda item]

Hello Robin,

Thank you for your insightful comments - my questions and comments 
inline below:

ext Robin Berjon wrote:
> Hi,
> 
> a few notes on the topic of APIs.
> 
> On Jun 18, 2009, at 21:12 , ashok malhotra wrote:
>> Recently, the W3C has greatly increased its focus on defining APIs  
>> [2,3].
>>
> 
> I am unconvinced that the increase is as strong as it is made out to  
> be. W3C has produced a fair number of APIs over the years: just the  
> sum total of all the DOM specifications, plus the HTML DOM, SVG DOM,  
> and CSS OM already add up to a lot of interfaces. The initial WebAPI  
> WG (now WebApps) was chartered a few years back with already a large  
> set of APIs in its remit. Before that, the SVG WG had been working on  
> a number of non-DOM APIs as well. And then there's Geolocation, DCI  
> (fka DPF) and a few others I'm probably forgetting about.

If you were to look at AWWW, however, would it give you a sense that it 
related to any of those efforts? Or would it give you the sense that 
since AWWW was created, W3C has "suddenly" begun working on APIs?

> 
> I think that the shift, if shift there is, has more to do with what we  
> are defining APIs to. The early ones were more internally oriented,  
> whereas the upcoming ones are turned more towards the outside world.  
> I'm unsure that this is an issue though, rather than simply a  
> manifestation of the fact that the web is extending its rosy fingers  
> well outside of the browser.
> 
>> This raises the question of whether the W3C TAG should offer further  
>> guidance to the developers of APIs, and whether (or how) that  
>> guidance should differ from that offered to the developer of a  
>> declarative language or protocol.
>>
> 
> I would add: and whether it should differ from guidance offered to  
> APIs previously defined within W3C.

Can you provide any pointers to the guidance offered to APIs previously 
defined within W3C?

[...]

> 
> Work on WebIDL is painstaking and understaffed — if we had had a  
> better option available I'm pretty sure that everyone would have been  
> happy to reuse it. I'm sure the WebApps WG would therefore welcome  
> pointers to viable alternatives within that "heady mix available on  
> the Web today" of which you speak.

I wasn't suggesting that there are any good alternatives to WebIDL, 
merely that we are creating an interface-definition language to 
complement the other languages available on the Web.

> 
>> • Revise the AWWW [1] to discuss the role of APIs and active content  
>> in general.
> 
> That would certainly be worthwhile. OMTP BONDI and WebApps have both  
> had heated arguments about versioning, to the point where asking which  
> version of the versioning argument we're on now has become a trite  
> joke.

That's good to know - if you could provide some kind of pointer to any 
of these discussions, that would be most helpful.

[...]

>> • The failure model may be different. If the implementation does not  
>> understand a statement, what does it do: error, crash and burn,  
>> ignore? In typical interface definition languages, this is handled  
>> by describing exception cases which are documented for a particular  
>> interface.
> 
> This should be up to the concrete implementation language, not the  
> IDL.

WebIDL allows the definition of exception conditions 
(http://www.w3.org/TR/WebIDL/#idl-exceptions). But what should happen if 
some Javascript is contained within a compound document, and an 
exception condition occurs?

I do think we should be carefully drawing the distinction between the 
interface definition language, the API implementation code, and code 
which uses the API.

> At some point the extensibility model has to hit the road, and  
> you can't usefully enforce support for a feature across languages. It  
> was tried with DOM's hasFeature(), which in practice produces  
> completely untrustable results.
> 
> 
>> • Subverting the traditional client-server model of the Web (by  
>> allowing a client to effectively serve Web content via an API call)  
>> has implications (particularly in the areas of security and privacy)  
>> for the relationship between a 	      client and a server.
> 
> I'm not sure that this is ever really happening. The client can write  
> to services — but that's always been part of the web (even if often  
> insufficiently so). If you're thinking about things like Opera Unite I  
> don't believe it changes anything: it's a client and it's a server,  
> and there's a nice UI to the latter in the former, but that's about  
> it. No architectural change.

I think there are (at least) privacy concerns when running a server that 
is "in my pocket". For example, if you consistently give out the same IP 
address, or other identifiers to some group of clients, those clients 
(which can play the role of servers too) can correlate that identifier 
and use it as an identifier closely related to a natural person.

If, however, you give out IP addresses which frequently change, in order 
to protect privacy, you have the condition that a proxy server is needed 
in order to contact the server-client, if that server-client desires to 
be readily available to the outside world.

I don't see that as an architectural change, but I do think it raises 
the emphasis on security and privacy related to the architecture.

I would also note that in the "traditional" Web model, servers usually 
expose resources, named with URIs. If, however, we expose resources as 
Javascript function calls (for example), what are the URIs which name 
these resources? What are the AWWW representations "returned"?

[...]

Regards,

- johnk

Received on Friday, 19 June 2009 12:35:00 UTC