Hi ko In the following I give some instant comments on your work. Regard all of it with a pinch of salt.
> I propose that the notification core queues events and fire them all > from time to time to the UI. In addition, only events that are > subscribed by the UI have to be queued. And if there are multiple UIs > running, only the subscribed data items have to be sent on a per-UI > basis. Recently I added event.[ch] to the sources. This allows to control the frequency of callbacks on a per-listener base. To avoid race-conditions and to keep it simple the current implementation does deliver only the first event in a given period and drop all following events occuring in the same period. Generally I would actually prefer real-time updates (no queuing) for some information (e.g. like adding and removing downloads). For other information I want only 1 update per second (like download status information). This is reflected in the various _info and _status structs in gnet.h. When an _info on an item changes, the gui should update immediately. For _status the gui should only query once in a while. > ** 3. Subscription Model ** > Yes, a little humor doesn't hurt these days. All those situations have > to be taken to our advantage in the core, spending only the resources > necessary to provide requested data, maybe slightly more if needed but > by all means we don't have to spend time computing XML packets for gnet > nodes when the only things the UI cares about is the current state of > download 0xff7e3c80. The current granularity of subscribtion is not enough for this case and probably should be improved, yes. > ** 4. Data Representation ** > > The current gtkg UI frontends use the same structures as the core to > perform updating. We want to have a generic notification system to gtkg, > so sticking to the core structures is the right way. We have to > translate them to XML, but we don't lose flexibility. Some struct > members, however, are useless for UI updates and should not be > translated. The current implementation does no longer use the same structs in the core and in the gui. That is only the case for parts of the code that have not been seperated into gui and core parts yet. Usually the core has a private structure and the gui uses the structs from gnet.h. Whenever information is passed on to the gui, the infomation is copied into an instance of one of the structs specified in gnet.h and the gui can take it from there. That is "data separation". No memory should be shared by gui and core. The downloads stuff you seem to base your argumentation on is not yet separeted. Please also have a look at the nodes and searches. > ** 6. Data Structure ** > > We need two more attributes in order to give structure to the XML > packets. One of them is a unique identifier that can be used to refer to > this particular object from the UI (the adress of the object can be > used, but may cause problems with memory allocators reusing addresses > between updates). Take a look at idtable.[ch]. This is currently used to manage the object ids shared between gui and core. > The other one is the object "state", or relation to the UI. There are > three states : NEW means it's the first time the UI sees the object, > MODIFIED means an existing object has been changed in some (subscribed) > way, and REMOVED means it's the last time the UI sees this particular > object (though the identifier may be reused later for another object). I think it would be best give "REMOVED" the following semantics: Hey gui, this object id is no longer valid. Please tell me that you recieved this message and that I may safely reuse the id, thanks. Can you please have a look at the files that I mentioned above: - gnet.h common data structured and functions exported to the gui. - event.[ch] "Advanced" event management. - idtable.[ch] Management of unique ids. - nodes.[ch] nodes_gui.[ch] Example of "separated" gui and core. - search.[ch] search_gui.[ch] Also example of separated gui and core. Btw: filtering is done in the gui code. This is maybe a bad idea, but it was simplest to do when separating the whole stuff. After you had that look, you may have some additional comments for us. Thanks very much for your effort ;) -- Richard Eckart <[EMAIL PROTECTED]> ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Gtk-gnutella-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-devel
