[cosmo-dev] Dojo topic stuff, was Web UI Documentation

[Matthew Eernisse]

Travis,

Responses are below ... :)

Travis Vachon wrote:
>> Creating a separate topic for each possible message that a particular 
>> UI element can respond to would seem to me to be analogous to having a 
>> large number of radio stations that can only one song apiece.
> 
> The topic system is very flexible and open ended, and I don't think your 
> metaphor provides good intuition for how it can be used.

I agree, it's very flexible and could be used a lot of different ways. 
Just saying, your initial argument for changing the approach was that 
the current system is "reimplementing functionality of topics," which 
doesn't seem to be the case, looking at the docs, here:

http://dojotoolkit.org/book/dojo-book-0-9/part-3-programmatic-dijit-and-dojo/event-system/publish-and-subscribe-events

The analogy of the PA system that they use to describe it sounds like a 
single channel passing lots of different messages, and the example code, 
passing messages to a "globalEvents" topic, looks a lot like what we're 
doing with the "/app" channel.

Of course, if there are benefits to be gained, perf or otherwise, it's 
definitely worth talking about making changes.

> Do you have any data on this overhead? Also, we aren't talking about 
> event.connect, we're talking about dojo.publish and dojo.subscribe. I'd 
> like to spend some time today putting together some performance data 
> that will hopefully give us better intuition about these tradeoffs, I'll 
> check it  into trunk so we can make it part of our eventual performance 
> test suite.

Yes, we are *also* talking about event.connect :) -- it gets called 
(specifically kwConnect) every time you call event.topic.subscribe to 
hook the thing up. The pub/sub system is built on top of the event system.

My original attempt at perf benchmarking is here:

http://lists.osafoundation.org/pipermail/cosmo-dev/2006-November/002126.html

I can't remember if this was Dojo 0.3 or 0.4.

The unbelievably bad initial benchmarking results for IE were due at 
least in part to running the tests in a VM (at first I thought were due 
to the 10ms/tick resolution on the Window system clock).

Later, running the same tests on a native XP box were not as bad, but 
still pretty horrible.

Just to verify it's still a problem, I did a quickie test 
event.connecting an onclick event to a function 200 times in IE6, and it 
took over 1800ms consistently.

The same thing with dojo.event.topic.subscribe takes consistently over 
2800ms. Doing it 500 times takes around 30 seconds. 1000 makes the app 
unresponsive. Here's the code:

var dtA = new Date().getTime();
for (var i = 0; i < 1000; i++) {
   dojo.event.topic.subscribe(
     'foobar_' + i, function () {});
}
var dtB = new Date().getTime();
var diff = dtB - dtA;
alert(diff);

The good news is that I did some more research -- and it turns out that 
event.connect is only horribly slow
in IE when you connect to a function object, and not to an 
object/keyword-string combo.

So it's actually nice and speedy to create lots of topic subscriptions, 
as long as we don't point them to inline functions -- something we ought 
not be doing anyway.

So, I don't have any perf objections to that approach -- if you and 
Bobby like that approach better, that's fine. And I think you're right, 
it could potentially give us a more responsive UI, which would obviously 
be great.

> The fallacy here is that each topic has only one possible response. 
> Of course, if two topics have only one possible response across the 
> application, they should not be two different topics.  Several of 
> the topics you list aren't like this at all.  In an ideal world we wouldn't
> re-render the entire widget for collection added and collection deleted, 
> we would just update the appropriate UI (dom nodes) accordingly, which 
> in this case would mean significantly different operations. On the other 
> hand, I can see an argument that "subscription updated" and "collection 
> updated" should not be separate topics.

I was talking about the reverse, multiple subscriptions to one response. 
In your initial code for the collection selector, there was already a 
subscription for renaming collections that pointed to a response 
function that triggers a re-render. Instead of pointing your new 
subscription to the same response function, you implemented yet another 
function right next to it that just called the same local re-render.

I wanted to make sure that this plan of one-topic-per-message-type 
wouldn't involve a needless profusion of handler methods that all call 
the same local method. Multiple subscriptions should be able to share a 
response handler.

Given the minimal difference in rendering time versus the dev 
time/effort to implement, those optimizations (like appending a row to 
the collection selector instead of re-rendering the thing) don't really 
seem desirable. I'm noting the phrase "in an ideal world" up there, but 
I find it hard to imagine a time when the return on investment for 
something like that would be worthwhile.

If you're talking about some of the bigger, more complicated pieces like 
the lozenges on the cal canvas, it makes more sense. But given how much 
the UI is likely to evolve now that people are using it, and how likely 
we are to be making changes to it as we go, I don't think we should 
invest a lot of effort those kinds of optimizations.

> Replace each of the current "actions" with a topic and add new topics 
> only when new functionality is added. Topics should be
> a) well defined (documented, defined in a well known spot in the code),
> b) general purpose (if it is hard to imagine why there would be multiple 
> subscribers, just make it a method call),
> c) sensible to a human being (e.g. "collection updated" not "x cleared")
> d) event oriented, non-imperative (e.g. "collection updated" not 
> "rerender").

All this sounds reasonable. I think most of the current actions will map 
directly to the kind of topics you describe.

Nice. work. :)


Matthew