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?
On Fri, Jun 8, 2012 at 3:42 PM, Erik Vold <erikvv...@gmail.com> wrote:
> I'd like a jetpack to be able to create an API that other addons can use
> to communicate with it.
> 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?
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?
> 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?
> --
> 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-labs-jetpack@googlegroups.com.
> To unsubscribe from this group, send email to
> mozilla-labs-jetpack+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/mozilla-labs-jetpack?hl=en.
> 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?
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.
On Sat, Jun 9, 2012 at 2:35 AM, ZER0 <z...@mozilla.com> wrote:
> 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?
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<https://addons.mozilla.org/en-US/developers/docs/sdk/latest/packages/...>which
I don't think is a great solution for a few reasons, but mainly
because it's not easily understood.
Erik
On Fri, Jun 8, 2012 at 6:27 PM, Jeff Griffiths <jgriffi...@mozilla.com>wrote:
>> 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?
>> --
>> 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-labs-jetpack@**
>> googlegroups.com <mozilla-labs-jetpack@googlegroups.com>.
>> To unsubscribe from this group, send email to
>> mozilla-labs-jetpack+**unsubscribe@googlegroups.com<mozilla-labs-jetpack%2B unsubscribe@googlegroups.com>
>> .
>> For more options, visit this group at
>> http://groups.google.com/**group/mozilla-labs-jetpack?hl=**en<http://groups.google.com/group/mozilla-labs-jetpack?hl=en>
>> .
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.
On Monday, 2012-06-11 at 09:38 , Erik Vold wrote:
> 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 (https://addons.mozilla.org/en-US/developers/docs/sdk/latest/packages/...) which I don't think is a great solution for a few reasons, but mainly because it's not easily understood.
> Erik
> On Fri, Jun 8, 2012 at 6:27 PM, Jeff Griffiths <jgriffi...@mozilla.com (mailto:jgriffi...@mozilla.com)> wrote:
> > I understand the specific usefulness of cheevos exposing hooks, but can you think of other, more general usage examples for this?
> > > 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?
> > > --
> > > 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-labs-jetpack@googlegroups.com (mailto:mozilla-labs-jetpack@googlegroups.com).
> > > To unsubscribe from this group, send email to
> > > mozilla-labs-jetpack+unsubscribe@googlegroups.com (mailto:mozilla-labs-jetpack%2Bunsubscribe@googlegroups.com).
> > > For more options, visit this group at
> > > http://groups.google.com/group/mozilla-labs-jetpack?hl=en.
> -- > E
> -- > 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-labs-jetpack@googlegroups.com (mailto:mozilla-labs-jetpack@googlegroups.com).
> To unsubscribe from this group, send email to mozilla-labs-jetpack+unsubscribe@googlegroups.com (mailto:mozilla-labs-jetpack+unsubscribe@googlegroups.com).
> For more options, visit this group at http://groups.google.com/group/mozilla-labs-jetpack?hl=en.
> 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.
> On Monday, 2012-06-11 at 09:38 , Erik Vold wrote:
> 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<https://addons.mozilla.org/en-US/developers/docs/sdk/latest/packages/...>which I don't think is a great solution for a few reasons, but mainly
> because it's not easily understood.
> Erik
> On Fri, Jun 8, 2012 at 6:27 PM, Jeff Griffiths <jgriffi...@mozilla.com>wrote:
> I understand the specific usefulness of cheevos exposing hooks, but can
> you think of other, more general usage examples for this?
> 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?
> --
> 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-labs-jetpack@**
> googlegroups.com <mozilla-labs-jetpack@googlegroups.com>.
> To unsubscribe from this group, send email to
> mozilla-labs-jetpack+**unsubscribe@googlegroups.com<mozilla-labs-jetpack%2B unsubscribe@googlegroups.com>
> .
> For more options, visit this group at
> http://groups.google.com/**group/mozilla-labs-jetpack?hl=**en<http://groups.google.com/group/mozilla-labs-jetpack?hl=en>
> .
> --
> 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-labs-jetpack@googlegroups.com
> .
> To unsubscribe from this group, send email to
> mozilla-labs-jetpack+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/mozilla-labs-jetpack?hl=en.
> --
> 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-labs-jetpack@googlegroups.com
> .
> To unsubscribe from this group, send email to
> mozilla-labs-jetpack+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/mozilla-labs-jetpack?hl=en.
> 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.
