[API] Windows Messenger JavaScript API

[Fabio Forno]

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.

>  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

>  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.

Bye,

-- 
Fabio Forno, Ph.D.
IBluendo srl http://www.bluendo.com
jabber id: ff at jabber.bluendo.com