Hi, Some free time, so here goes another round ;)
> > 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.
>
> 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.
We agree here. From what I can see, the structs in gnet.h are supposed
to be the UI-specialized counterparts of the core structs. Suits me fine
:)
> The downloads stuff you seem to base your argumentation on is not yet
> separeted. Please also have a look at the nodes and searches.
This is real bad luck, sorry :/
I've looked at the whole code now.
> Take a look at idtable.[ch]. This is currently used to manage
> the object ids shared between gui and core.
And is exactly what pointers should translate to in the XML model,
thanks :)
> 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).
> ...
> 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.
Now that's interesting. Please correct me if I'm wrong :
- *_status structs should be passed to the UI when the time comes
(every second, tunable, etc)
- *_info structs should be passed immediately to the GUI, and some
(if not all) require an acknowledgment from the UI.
At the moment I think we must get this part right. IMHO if major updates
(*_info structs) require an ACK then we should also accumulate them in
an XML packet and send the batch every 10th of second or so ("real-time
updates" scare me for bandwith reasons, and remember you'll have to wait
for the ACK anyway).
I'd really like to discuss this issue. All comments more than welcome.
> The current granularity of subscribtion is not enough for this
> case and probably should be improved, yes.
That's where using XPath is handy. As I posted before, with a good
enough structure anything and any depth can be queried (let's say again
that I'm talking about core<->UI comunication here, not gnutella or
anything).
> 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.
This IMHO will need to be put in the core if we ever find a way around
*sob*.
> Thanks very much for your effort ;)
Thanks for yours. I just wish I had more time...
Cheers,
ko [junkpile at free dot fr on this platform]
signature.asc
Description: This is a digitally signed message part
