Re: 2 APIs and the charter

Henry,

I'm sorry you're getting mixed signals. I for one disagree with Harry's 
unproven claim that addressing two deliverables with one spec would 
require rechartering. So, I advise not to spend more time on discussing 
whether a rechartering is necessary or not.

I think Sandro has it right. The assumption is that two protocols are 
necessary. If it happens that we find out that one can do both so much the 
better but we won't know that until we figure out what's needed for each 
of them.

Best regards.
--
Arnaud  Le Hors - Senior Technical Staff Member, Open Web Standards - IBM 
Software Group




From:   "henry.story@bblfish.net" <henry.story@bblfish.net>
To:     Evan Prodromou <evan@e14n.com>
Cc:     public-socialweb@w3.org
Date:   02/11/2015 09:49 PM
Subject:        Re: 2 APIs and the charter




> On 12 Feb 2015, at 03:54, Evan Prodromou <evan@e14n.com> wrote:
> 
> On 2015-02-11 08:53 PM, Sandro Hawke wrote:
>> 
>> I agree with your reading of the charter, etc, but I think it still 
makes sense to imagine two distinct APIs. 
>> [...]
>> 
> Sandro,
> 
> Very well said.
> 
> I think having only a client-to-server API is an interesting exercise 
that doesn't scale well. It gets particularly tricky if you support 
following. Either you have:
>                • a polling mode where clients repeatedly fetch the feeds 
of every person the user "follows" and merges them into a single "inbox" 
feed on the client side, or
>                • the client has to write every update to every 
follower's server-side inbox feed each time the user updates.
> In either case, it gets really unwieldy at scales of dozens of 
followers, much less the tens of thousands you see on a site like 
identi.ca or the millions you see on a site like Twitter. Fan-out, 
retries, and exponential backoff become pretty hard to manage from a 
smartphone application.
> 
> On top of that, you need to have a universal authentication system that 
allows Alice, with an account on serverA, to write data as Alice on 
serverB (and to read data, if you have any kind of privacy controls). 
Probably client-side certs, I'd imagine from Henry's perspective, but 
that's a hard sell.
> 
> -Evan

That is an interesting interpretation of the charter, along with those by 
Erik Wilde, and Sandro Hawke  that preceeded. Here are some comments.

 1) That LDP is mentioned in the « Federation Protocol » does not fit very 
well with the above reading. I can see how  one can use LDP to develop an 
API for a « server » Actor to  request to be updates about changes to a 
resource on another machine, but that is an incredibly specific and 
unusual application of LDP. It is much more likely that LDP would be used 
for what the charter calls the  « social API ». So that is just another 
piece of evidence that the Charter is confusing. 
    Given these inconsistent readings of the charter, and the 
inconsistencies in the charter, it seems to me that  the charter cannot be 
brandished as a unambigous   guide  how we must proceed, as it has been 
recently. 

2) Optimizations: 
What is efficient will depend on the type of Social Web Server. 
 a) Personal Server: 
   If it is for example a piece of software running on a machine designed 
for an individual/family such as the Freedom Box [1], then one server will 
need to go and fetch the data for all its users in any case. Opening 
thousand or 10 of thousand connections is totally feasible without memry 
overload if you use the C select call [2] - which is how the  crawlers 
were written at AltaVista. The equivalent in Java is the NIO framework, 
which is used by libraries such as Netty (the core of Jboss). And of 
course modern functional languages such as Scala with Actor programming 
frameworks such as  http://akka.io  make it much easier to program these 
very efficiently. These are now well known to JavaScript programmers as 
asychronouns frameworks. To sum up: a Freedbom Box should be able to open 
10 thousand connections and only use up 4 threads.
  Notice that here there is of course no reason why the iPhone client 
should be making those connections, which would of course have it run out 
of battery quite quickly. But by specifying an API as client/server in the 
sense of a specification of the communication along the wire -  it would 
of course be the role of the Freedbom Box to fetch remote resources in the 
background.
 b) enterprise server: we can discuss the issues involved here

What the existence of a) indicates is that there should be an API that 
covers all the user stories, and an optimisation API for larer structures, 
and plain and simple optimisations. But if this is the case then the user 
stories is not the place to distinguish the APIs. 

3) This does not mean that a notification system would not be very useful 
too (even for a FreedomBox), as a way of avoiding « client » polling ( 
where the « client ». can be the FreedomBox ) It is true that a 
notification system will really only work well when the machine making the 
request notification is always on - so I can see why one could think of it 
as a « server » protocol. 

4) For authentication and Web Access Control issues I don’t suppose the 
group is about to build a new authentication protocol. That seems like it 
should be the work of a separate group. We just have to assume we have it 
available.
By the way X509 Client Certificates work just as well for « servers »  as 
for « clients ». In fact is is a lot easier to use authentication on the « 
server » because there the developer has full access to all the features 
of the TLS stack.

So in conclusion:

  I don’t see that we really have a way from the charter to be able to 
sort user stories into ones that would fit the « social API » and ones 
that would fit « the federated api ».  Apart from the inconsistencies in 
the charter it seems that the second API is more of an optimisation API 
which should not be visible from the user stories.

Also we need to find a way to use "client/server" in a way that does not 
clash with most internet engineering tradition. What is needed is a word 
for machines that are always on, and machines that are close to the human 
actor, and that may easily be off for a while. Then we will find that all 
our APIs ( if more than one is needed ) are client/server, but that some 
APIs are for machines that are always on.


Henry

[1] http://en.wikipedia.org/wiki/FreedomBox

    and a short video by Eben Moglen author of the GNU public licence
     http://vimeo.com/20034456

[2] http://linux.die.net/man/2/select


Social Web Architect
http://bblfish.net/