[API] Distribution method (was Re: Jabber "API")

[Pedro Melo]

Hi,

On Mar 2, 2008, at 3:12 PM, Fabio Forno wrote:
> On Wed, Feb 27, 2008 at 1:52 PM, Pedro Melo <melo at simplicidade.org>  
> wrote:
>>  2. Deployment choices
>>
>>  Given that the existence of HTTP client is more or less ubiquitous,
>>  and that we also want to support Web-based clients, my gut feeling
>>  tells me that the best way to distribute this apps is via HTTP, with
>>  an optional XMPP mechanism.
>>
>>  I would feel better to use XMPP, but I don't see a clean way to  
>> do it
>>  for now, given that File Transfer is not reliable right now.
>>
>>  So we are left with HTTP. The way I see it, anybody could publish a
>>  xiclet by putting the resources needed in a web server. There would
>>  be a manifest-type file, in XML or JSON, with all the information
>>  needed to download and start using it.
>>
>>  Other information (like the requirements, author, and probably
>>  digital signature) would also be available.
>>
>>  The URL would also be used as the namespace to qualify the extra
>>  stanza information we would transport. This would make it easy for
>>  receiving applications to know where the Xiclet is.
>
> Before considering how to get archive with the application, we need to
> know how to discover and retrieve the manifest file describing it.

Well, the namespace we would use in XMPP land to tag all the stanzas  
as belonging to the app, would be the manifest file.

> This will be based on XMPP mechanisms (better if we use something
> which is already available) and it should have these features:
>  * users can browse for applications and get them clicking on the  
> related node
>  * the mechanisms should be consistent between server hosted and p2p
> applications
>  * users and agents can push the manifest to other users, who should
> accept or deny the invitations
>  * the mechanism should support as well one shot applications (e.g. I
> want to play chess with a buddy and I send him the applications) or
> permanently downloaded xiclets
>  * applications should be able to refer to other applications
>  * it should be possible to upgrade the application once installed  
> on a node

I'm sure that as all other plugin type stuff, a directory will emerge  
somewhere. A web interface will be available for that directory,  
probably with a mime-type for the manifest file that can trigger XMPP  
clients to do the right thing.

Of course, we could have also have a disco and jabber:iq:search  
interface to the database, but I expect most people will find out  
about applications via a web site.

I don't expect users will want to accept applications p2p, unless you  
really trust the other user. Personally I can count with one hand the  
number of people I would trust with that. It will really depend on  
the security model we can impose on this xiclets. But of course, how  
can we know if the application from the hosted site is good, also.  
Trust is always difficult.

I don't distinguish between permanent downloaded widgets and one-time  
widgets. Both have to be downloaded completely to local storage to  
work, I imagine. Or maybe not... I don't know how willing a xiclet  
author is to pony up for the cost of hosting all the hits to his  
application, per resource, per usage. But I can imagine a scenario  
where such a distinction could be useful in managing a loca cache of  
applications.

I don't know what you mean by "applications should be able to refer  
to other applications" though...

For the application upgrade, I see two solutions: a classical pooling  
solution where the manifest includes a version URL that the user must  
HEAD from time to time to discover a new version (comparing etags).  
This URL can be the manifest itself for simple applications.

Another solution is a pubsub node that you could subscribe to be  
notified of new versions. I see this as an excellent add-on for  
application directories sites.


going back to discovery stuff, I imagine that we should include at  
least the capability of running applications in the disco#info response.

For some time I was assuming that we could also include all the  
applications we support right now in the disco response, but I  
changed my mind during The Latest 115 Discussion. I think we should  
try and keep 115 stable to improve cache-ability of disco response,  
so a single namespace in there, meaning we support xiclets, is enough.

We can then either do a disco#items on a well-known xiclet node to  
find out which applications I have, or not even bother with that and  
just send the session start request for a specific app. And I can  
accept or reject it, and if I accept, I can fetch the manifest and  
all the other resources.

On the other hand, certain applications might need to modify  
disco#info response. For example, a calendar application might want  
to modify disco#info response to announce that this client now  
supports meeting request negotiation or a free time API of some sort.

So although I don't expect we publish all our apps to disco#info, I  
see a need to let them access it.


> All these features tells me that pubsub (and pep) could be the correct
> way to publish the manifest of the application:
>  * it's possible to browse the contents
>  * updates are pushed
>  * loose coupling between applications producers and consumers
>  * it's not forbidden do do direct push of the manifest through a  
> <message/>

I like pubsub for this, but finding out which applications are  
available I think will be done over the web in most cases.

Of course, the install now button could be a xmpp:-style URL to  
subscribe to the application node in the end....

> The manifest should contain at least the description of the
> application, required permissions and how to retrieve it. The download
> method can be either http as Pedro is proposing, ibb, or some xml
> stream if application contents are often updated.

I think HTTP and IBB should be the backups, always works scenario.

I was not at the DevCon when you guys discusses file transfer (and I  
admit I haven't read through all of Peter's notes), so maybe there is  
some more information I need to adjust to.


> If you like this approach we may start writing the use cases as if
> they were a xep, describing in particular:
> * the publishing model
> * the format of the manifest

I prefer to discuss this over real proposals of formats and  
protocols. Maybe that's jumping the gun, but I always feel better  
seeing the file formats and protocols flowing by, so I don't see  
anything holding back from starting this.

Personaly, I have three action items on my side:

  * finish reading through Sameplace site and docs: given that it  
already does a lot of stuff we want to do, I want to have it in my  
mind while we discuss this;
  * draw a quick architecture diagram for the solution, as I see it:  
i'm a visual person :)
  * start a prototipe JS API for this.


Best regards,
-- 
Pedro Melo
Blog: http://www.simplicidade.org/notes/
XMPP ID: melo at simplicidade.org
Use XMPP!