[API] Windows Messenger JavaScript API

[Pedro Melo]

Hi,

On Mar 3, 2008, at 2:13 PM, Fabio Forno wrote:
> On Mon, Mar 3, 2008 at 1:45 PM, Pedro Melo <melo at simplicidade.org>  
> wrote:
>>> - should the xiclet be able to access your roster?
>>> - may it send messages using your jid to any contact?
>>> - may it listen for incoming messages from any contact as well?
>>
>>  Right I would say: no, no, no.
>>
>>  But those are my initial position, and are not absolute.
>>
> No is my same answer for the default behavior, but just for it
>
>>  Let me take the last two first.
>>
>>  I see all communication between IM Client <-> Xiclets (and I use the
>>  term IM Client loosely, it could be a Web Interface like JWChat) in
>>  terms of a context with communication channels.
>>
>>  For each app running there is a application instance object. This
>>  instance has an API to create a communication channel. The
>>  application can only see and or generate messages in that channel. A
>>  typical channel is a one-to-one chat session, maybe using  
>> <thread> to
>>  keep it separated from the rest, or a MUC room, created for this
>>  application instance.
>
> And that's exactly the default restricted sandbox I'd like to offer.
> But I want also a mechanism solving what I feel is the greatest
> limitation of pubsub at this moment; let's make a practical example:
> - a new service publishes news through pubsub
> - a user wants to subscribe to that service, but it can't unless the
> client has special support for that service and that particular
> content
> You may say: well RSS readers are so common that sooner or later
> clients will have support, but this is what we are trying to avoid.
> With strict limitations, these applications can be sent only by the
> publish subscribe system itself and not from another node, thus
> limiting the possibility to deploy these applications to server admins
> I don't know if we need a general purpose mechanism for listening to
> incoming messages, or all we need is just the ability to subscribe to
> pubsub nodes (e.g. ask the permission during installation: may i use
> this pubsub service?), but I'd really like to allow it.

How are you thinking on mapping Apps to nodes? A app per content  
type, or a App per node (or set of nodes)?

In other words, a App should describe itself as "Hi there, I'm  
capable of displaying Atom Items to you!" and we need to map all  
events with a Atom entry payload to it, or as "Hi there, I'm the CNN  
xiclet! and I can show you CNN headlines in realtime!"...

The last one matches my current view of this, although it is more  
restricted than the first. If you take the second row, then I suppose  
we can use the same origin policy and all widgets available from  
'*.cnn.com' can subscribe to topics at any domain '*.cnn.com' without  
my permission.


>>  The environment would give some sort of API to invite people into a
>>  channel. And this takes us the to the first bullet. I think we can,
>>  for now, deny roster access if we provide a invite_into_channel API.
>>  This way, the client can choose whatever method is better suited for
>>  selecting buddies and invite them into the channel, without giving
>>  access to the roster.
>
> If get it well,  it's the client UI that handles the invite stuff, not
> the xiclet (as it does now for mucs). It seems reasonably functional

cools


>>  Not giving access to the roster now, allows us time to think about
>>  all the implications. A future version might relax those  
>> restrictions.
>
>>  Its easier to give something in the future, than to take it back...
>
>>> Besides msn, sameplace and meboo other relevant communities?
>>
>>  Yes, and the kool appz OpenSocial and what not. We might want to  
>> have
>>  a "profile" or "mode" in which our Xiclets become a OpenSocial
>>  container.
>
> reasonable
>>  What about a geek aproach? A shared subversion repo where you can
>>  write those docs?
>
>>  It would be nice because we could also commit examples ...
>>
>>  But a wiki is also fine. I suggest wiki.jabber.org.
>
> Both things, as scratchboard I prefer a wiki. If it's relevant for XSF
> Id stay there, perhaps we get more interested people.

Lets start with the wiki and see how that goes?

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