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-tp4247446p4249136.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
