gmurray

that's what i meant (it would be good there)

gmurray

craig : agreed

craigmcc

(and it requires the change you advocated, to support both 'publish' and 'subscribe' arguments so you can have both)

gmurray

the other option would be to have a glue subscriber in the glue.js that would forward a request to your own custom listener

carlavmott

I see you want to add something. so why not have a addPublisher or addSubscriber?

gmurray

also being in glue.js

craigmcc

PLEASE don't make me write my own javascript when I can declare things

gmurray

ic

norbert

By optional, I'm thinking about whether explicit pub/sub in the args should override the default behaviors in the widget.json ... I'd prefer that override=false be the default but could live with the opposite

ntruchsess

overwrite=false is not something I'd expect as a user of the widget

ntruchsess

where should the user specify whether he wants overwrite=true?

craigmcc

args="{publish:'mytopic' publishOverride='true'} or something

carlavmott

what does that mean? I don't understand what is overridden

craigmcc

that way, for example, I could add an additional listener on a map without breaking the default one that listens to the geocoder

ntruchsess

hmmm... doesn't look very intuitve to me.

craigmcc

publishOverride means do not publish to the 'publish' topic(s) in 'widget.json' ... ONLY publish to the ones I list in the 'publish' argument

ntruchsess

craig: you wouldn't add the addional listener to the map in the map's args anyway

craigmcc

why not? it's easier than having to write javascript to do it

ntruchsess

craig: you would do this by specifying the listentopic in the args of the listener

ntruchsess

craig: that is my intention too

craigmcc

it sounds like we might want to have a more extended wiki discussion on this stuff too, along with data models and such

gmurray

we are close I think gmurray: I also don't want to make the widget development too hard

craigmcc

with some use cases to illustrate what it would actually look like

gmurray

seems like alot of this is repeasted work

craigmcc

(1) why is it hard? a couple of shared helper methods in jmaki.js could handle the auto-registration stuff for all widgets

craigmcc

(2) there are two different users of this stuff ... widget developers and application developers ... and we need to make life as easy as possible for both, but there will be LOTS more app developers

Discussion on publish and subscribe mechanism in jMaki.

-- Main.carlavmott - 17 May 2007 Discussion on publish and subscribe mechanism in jMaki.

Inlcude are some excerpts from the IRC meeting on the subject. This is just to get us started from the last discussion.

norbert

By optional, I'm thinking about whether explicit pub/sub in the args should override the default behaviors in the widget.json ... I'd prefer that override=false be the default but could live with the opposite overwrite=false is not something I'd expect as a user of the widget where should the user specify whether he wants overwrite=true? args="{publish:'mytopic' publishOverride='true'} or something what does that mean? I don't understand what is overridden that way, for example, I could add an additional listener on a map without breaking the default one that listens to the geocoder hmmm... doesn't look very intuitve to me. publishOverride means do not publish to the 'publish' topic(s) in 'widget.json' ... ONLY publish to the ones I list in the 'publish' argument craig: you wouldn't add the addional listener to the map in the map's args anyway why not? it's easier than having to write javascript to do it craig: you would do this by specifying the listentopic in the args of the listener craig: that is my intention too it sounds like we might want to have a more extended wiki discussion on this stuff too, along with data models and such we are close I think I also don't want to make the widget development too hard with some use cases to illustrate what it would actually look like seems like alot of this is repeasted work (1) why is it hard? a couple of shared helper methods in jmaki.js could handle the auto-registration stuff for all widgets (2) there are two different users of this stuff ... widget developers and application developers ... and we need to make life as easy as possible for both, but there will be LOTS more app developers that's what i meant (it would be good there) craig : agreed (and it requires the change you advocated, to support both 'publish' and 'subscribe' arguments so you can have both) the other option would be to have a glue subscriber in the glue.js that would forward a request to your own custom listener I see you want to add something. so why not have a addPublisher or addSubscriber? also being in glue.js PLEASE don't make me write my own javascript when I can declare things ic