Cross addon communication

[Erik Vold]

I'd like a jetpack to be able to create an API that other addons can use to communicate with it.

Here is a use case: https://github.com/msujaws/Cheevos/issues/10

So old school addons and jetpacks both will need to be able to communicate with Cheevos in the above example.

I'm thinking that I could setup a user friendly resource uri and provide a jsm that would send json so my jetpack (somehow) would suffice, but I'm wondering if anyone has a better idea?

Thanks,

Erik

--
E

[Erik Vold]

Maybe an internal change would be best? adding a new method to https://developer.mozilla.org/en/Addons/Add-on_Manager/Addon that only work for jetpacks would be nice.

Erik

--
E

[Jeff Griffiths]

How do you see the security model working here - it seems like the
initial add-on ( let's say it is cheevos ) would need to provide some
sort fo callback mechanism that the 'client' add-ons would pass messages to?

I understand the specific usefulness of cheevos exposing hooks, but can
you think of other, more general usage examples for this?

Jeff

> E<http://erikvold.com/>
>
>
>
>
> --
> E<http://erikvold.com/>
>
> --
> You received this message because you are subscribed to the Google
> Groups "mozilla-labs-jetpack" group.
> To post to this group, send email to mozilla-la...@googlegroups.com.
> To unsubscribe from this group, send email to
> mozilla-labs-jet...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/mozilla-labs-jetpack?hl=en.

[ZER0]

On 06/09/12 24:42 AM, Erik Vold wrote:

> I'd like a jetpack to be able to create an API that other addons can use
> to communicate with it.

[..]

> I'm thinking that I could setup a user friendly resource uri and provide
> a jsm that would send json so my jetpack (somehow) would suffice, but
> I'm wondering if anyone has a better idea?

During last conference I was, I explained how a page can query Firefox
to discovered if an Add-on is installed or not, and use the
functionality the add-on provides. Is it something similar?

First of all, the add-on has to explicitly allows this; then the page
can send a `postMessage` to itself to "check" if the add-on is present
(like an handshake) and if it is, use it with `postMessage` APIs.

Currently to do that we have to involve page-mods and the communication
between webpage and add-on is not so straightforward (the `onmessage`
event handlers in the page and in the content script receive both the
messages, also the ones sent by themselves); but I like the fact that
the add-on have to explicitly allows a set of pages to use it, and that
the communication are over `postMessage` APIs, for security reasons.

Maybe we could improve that, and implement similar mechanism for cross
addon communications, to be consistent?

[Erik Vold]

Yes, this does sound similar to what I'd like to have.

I certainly only want a postMessage/onMessage interface for security, and asynchronous communication.  Also it should not use an existing channel, and be opt-in.

I think I can write a prototype module that would slightly alter the addon manager jsm, or merely wrap it, to add these postMessage/onMessage methods to returned Addon instances.  Then there would be a module provided for jetpacks which could be used to post/listen to these messages on the jetpack's end of the line.

The latter part would be similar to your example I think ZER0.

Erik

[Erik Vold]

I can't really think of how to refine the usefulness in to a generalization, other than to say it would allow add-ons to easily communicate, which they sometimes need to do for various odd reasons.  There doesn't appear to be a easily understood solution for this problem when it arises too, and people are coming up with ad hoc solutions for it at the moment.  I think the most common solution is to use the observer-service which I don't think is a great solution for a few reasons, but mainly because it's not easily understood.

Erik

To post to this group, send email to mozilla-labs-jetpack@googlegroups.com.

To unsubscribe from this group, send email to

mozilla-labs-jetpack+unsub...@googlegroups.com.

For more options, visit this group at
http://groups.google.com/group/mozilla-labs-jetpack?hl=en.

--
E

[Irakli Gozalishvili]

Erik I think it would be great if you could write up a JEP

https://github.com/mozilla/addon-sdk/wiki/JEP

With an examples showing how such API can be used. In terms of implementation I think https://developer.mozilla.org/en/nsiobserverservice is a way to go about it.

While I'd absolutely love to see such module in user space, I'm not sure it needs to be part of the core sdk. Starting as a user space module feels to me a best  start.

Regards
--
Irakli Gozalishvili
Web: http://www.jeditoolkit.com/

To post to this group, send email to mozilla-la...@googlegroups.com.
To unsubscribe from this group, send email to mozilla-labs-jet...@googlegroups.com.

[Alexandre poirot]

It would be cool to take a look at was is being made in boot 2 gecko,
they are trying to use a web standard for that:
  https://wiki.mozilla.org/WebAPI/WebActivities
  http://en.wikipedia.org/wiki/Web_Intents

2012/6/13 Irakli Gozalishvili <rfo...@gmail.com>

[Ben Bucksch]

On 09.06.2012 03:27, Jeff Griffiths wrote:
> I understand the specific usefulness of cheevos exposing hooks, but
> can you think of other, more general usage examples for this?

Jetpacks addons are supposed to be small. Let's say Yahoo wants to offer
addons for their services: mail, storage, calendar, whatever. In Jetpack
philosophy, they should be separate addons that the user can install and
uninstall separately. But they all have a single login: Once you log in
to mail, you should also be logged in to calendar. Thus, the addons need
to share the login.

Ben