incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gord Tanner <>
Subject Re: [DISCUSS] Switching out Channel's in callback-js for an event module
Date Tue, 06 Dec 2011 22:09:31 GMT
You can probably see where I got the inspiration from then ;)

The API is basically the same as the EventEmitter except that the
EventEmitter from node allows you to new up other event emitters, where our
module is a singleton instance.

I wouldn't know where to store the instance of the eventEmitter if we did
use the node pattern.  Ideally we shouldn't need to import anything into
the window object (other than the device APIs) so that would rule out
making window.PhoneGap an instance of an event emitter.

I personally like the lack of flexibility of having one central place where
all events are triggered and acted upon.

Basically we ether end up with:

PhoneGap.on("foo", func);

- allow multiple instances of EventEmiters
- can be used as a base class.
- Syntax that is close to what we have now.

- forces storage of shared eventEmitters in the global space

var event = require("phonegap/event");
event.on("foo", func);

- can be used in a decoupled fashion in any module
- no requirement of hanging shared emitters off of the window object
- all events are funneled by the same emitter.

- only one event emitter to rule them all.
- all events are funneled by the same emitter.

I personally am liking the EventEmitter Approach a lot more as I would like
to have the ability to separate some of the events by instance:

var phonegap = require("phonegap");

phonegap.on("nativeready", func);

var network = require("phonegap/network");
network.on("ready", func);

var device = require("phonegap/device");
device.on("ready", func);



On Thu, Dec 1, 2011 at 5:12 PM, Patrick Mueller <> wrote:

> On Thu, Dec 1, 2011 at 16:48, Gord Tanner <> wrote:
> > Please see reference branch here:
> >
> >
> > One of the issues with Channel's in a module based system is that it is
> > awkward to keep track to a central repository of channel objects.
> I guess I'm a n00b.  I don't know what a Channel is.
> > I coded up a quick prototype using an event module.  This gives us the
> > ability to trigger and sync on events by just using a string (rather than
> > an instance created before hand). It cleans up some of the code and
> doesn't
> > require the pre-construction of all the channels before hand.
> Your API is actually fairly close the nodejs's "events" module:
> Close, but different.  In addition to the shape being different, the
> receiver/subject of the functions/methods is different - in your case,
> the subject is a global string identifying the event itself; in node's
> case, events are objects which are instances of EventEmitter, with
> method names closely corresponding to some of your function names.
> So, here's an alternative strategy:
> - implement a compatible nodejs "events" module
> - implement a separate module which has a list of the global events we
> think we'll need, with the ability to add more, somehow.  Those global
> events would, of course, be instances of our compatible EventEmitter
> class.
> The only thing I wonder about is "implementing a compatible version of
> a nodejs module".  You'd think that would be a kosher thing to do, at
> least if you did it in a clean-room fashion.  But, who knows these
> days.
> --
> Patrick Mueller

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message