Hi, I sure will try your demos if I get to this topic. Currently I don't want to spend that much time on topics not currently on my agenda. Your argumentation about the protocol sounds reasonable. I haven't found that I looked for the comet stuff. Best, Martin
panyasan wrote: > > > > > MartinWittemann wrote: >> >> 1.) Its quite interesting that you worked on that topic. I toke some time >> (but not that much as you) to try comet as well. You can see my chat >> (using qooxdoo and node.js) on github: http://github.com/wittemann/Chat >> Its not that much code and not working very well but it was a project for >> me to get to know comet. So I think it could be quite useful for qooxdoo >> to have some kind of comet support. The cometd is completely new to me so >> I cant say anything about it. But I will take a look at it. >> > > That would be great. I'd appreciate if you could try out the demo locally. > At least to me, it seems to make more sense to use the cometd > client/server solution provided by the dojo project than to invent yet > another comet protocol and to write another set of servers. As I said, if > you search the net, you will find a lot of lament about the used protocol, > called Bayeux, which is said to be overblown. I actually do not care much > from a user's point of view, since it works very well (at least with the > provided java server). As I write in the qx-cometd project page, one > major thing that still really bugs me is that I cannot easily translate > the used transport mechanism from dojo to qooxdoo (see cometd/Client.js), > so I still need to include a minimal dojo library. But with the help of a > transport expert, this could be remedied. > > > MartinWittemann wrote: >> >> 3.) That sounds really great and thanks for the kudos. :) It's something >> we have on our agenda for 2010 for sure. Even better that you are already >> on that topic. >> Have you ever made some performance tests with huge trees? The advantage >> of the virtual tree/table is to handle huge sets of data and I don't know >> if the data array can handle that amount of data very well. >> > > If you run the demo, you'll see the "Inbox/Spam" folder, containing 3000 > messages - no problem so far. If you have time, you could try and increase > the number of messages to see whether or qx.data.Array will choke. > > > MartinWittemann wrote: >> >> You have sure recognized the reorganization of the io namespaces >> recently. I think we should tackle the whole io layer in the near future >> and get that back to a good state. So maybe there will be something like >> a rpc data store (http://bugzilla.qooxdoo.org/show_bug.cgi?id=2993) which >> you have on your todo. >> > > I already started such a store, maybe it is of use? > > https://qooxdoo-contrib.svn.sourceforge.net/svnroot/qooxdoo-contrib/trunk/qooxdoo-contrib/VirtualData/trunk/source/class/virtualdata/store/JsonRpc.js > > Cheers, > > Christian > > -- View this message in context: http://n2.nabble.com/qooxdoo-contrib-cometd-Dialog-and-VirtualData-tp4247446p4249355.html Sent from the qooxdoo mailing list archive at Nabble.com. ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
