639518 - Create a Cross Add-on registry and communication service

Status: RESOLVED WONTFIX

(DevTools :: General, defect)

Description

[Rob Campbell [:rc] (:robcee)]

For the Devtools SDK, we are going to need a mechanism for different addons to communicate with one another. I think the API should probably look something like:

handle = devtools.registerAddon(name/id)

// handle is the output of the devtools.registerAddon method. It is likely the local endpoint of the this addon's remote interface.

handle = devtools.lookupAddon(name/id)

// handle is the output of the lookupAddon method. In this case, handle is a proxy to the remote object's interface.

handle.send(subject, object)

object = handle.retrieve(subject)

We might also want to be able to post messages / objects to a generic location for various addons to pick up. Also, we might want to mimic the nsIObserverService notification API to be able to pickup objects of a certain subject.

Comments?

Comment 1

[Mihai Sucan [:msucan]]

1. I am not sure what's the difference between the handle returned by registerAddon() and lookupAddon()?

2. Instead of handle.send()/retrieve() I would prefer to use a jetpacky approach:

In addonA:
handle = devtools.registerAddon("addonB");
handle.on("message", callback);

In addonB:
handle = devtools.lookupAddon("addonA");
handle.postMessage(message);

That's as light-weight as we can get, without needing send()/retrieve() nor any additional nsIObserverService-like notification API.

Comment 2

[Rob Campbell [:rc] (:robcee)]

(In reply to comment #1)
> 1. I am not sure what's the difference between the handle returned by
> registerAddon() and lookupAddon()?

they were meant to be endpoints -- registerAddon, the "local" endpoint, and in lookupAddon, the "remote" endpoint. Substitute local and remote for "handle" and it should make more sense.

> 2. Instead of handle.send()/retrieve() I would prefer to use a jetpacky
> approach:
> 
> In addonA:
> handle = devtools.registerAddon("addonB");
> handle.on("message", callback);

hum. That does make sense. I was thinking in terms of when we went to "send an object over the wall", but I guess there's no reason we couldn't do that via the callback on some event occurrence.

> In addonB:
> handle = devtools.lookupAddon("addonA");
> handle.postMessage(message);
> 
> That's as light-weight as we can get, without needing send()/retrieve() nor any
> additional nsIObserverService-like notification API.

Does that give us enough or do we need both protocols?

Comment 3

[Mihai Sucan [:msucan]]

I think it does. For one, you send and receive the data you want, and secondly you also get the event-based behavior of the nsIObserverService.

We should probably aim for the postMessage() implementation first, and see if that suffices our needs. I am more of the principle: don't add it if you don't need it.

Comment 4

[Rob Campbell [:rc] (:robcee)]

it is a good principle. :)

Comment 5

[Kevin Dangoor]

I have a feeling that if we work under the assumption that shared functionality will live in the browser itself then we probably won't need a general mechanism for this.

Perhaps we should close this bug and just open bugs for registries for specific services (like the command line?)

Comment 6

[Rob Campbell [:rc] (:robcee)]

acceptable.