Hi Emile! Long time no see. Nice to see you working on gtkg again.
> All the shared structs, etc. have > been moved into new interface files (eg. > gui_core_interface_fileinfo_spec.h) and all gui<->core function calls > are now routed through a set of interface functions. There already are interface files (gnet.h and gnet_*.h). In those the interface functions from the core are exported and shared structs are defined. Why do you want to move them to yet another set of files? > There's four sets > of files really, "gui", "core", "interface", and "common > libraries" (routines that gui and core can share). When I worked on the separation, I identified three different "sections". Core, gui and common (shared code). What is "interface" for? > file.h/c depends on ban.h. That may be a problem. > b) search_gui_common is the only gui file that uses file.h (I think). > It uses it to read in the "Searches" file. We may have to move this > code into the core and provide a function that's accessible through the > interface so the gui can retrieve the stored searches from the core. > This makes more sense than "a)", especially if we're talking about web > interfaces, multiple gui clients, etc. If search_gui_common used file only to read in the "old" searches file, then the dependency can be removed and file.h can be moved to "core". It would be even better though to move the persistance of the searches from the gui to the core entirely. Otherwise, file.h and ban.h need to be untangled. I think the gui should not depend on the core for sawing it's configuration. > 2. I haven't yet done the property tables, this is what I'm going to do > next (before the abstraction). The problem with the properties is not getting and setting them. That should be separated very well already. Adding a function to get/set props by string name is only syntactic sugar. The real problem is to handle the callback functions in a better way. Currently this is done by a quite evil but powerful #define hack. I would prefer talking to you about that on IRC. > So the gui could do something like > "gui_core_interface_call_core_function( "download_new", [parameter > list])" What's the problem in calling a function directly? If the core and the gui are in separete processes, then you just have to add a transparency layer for the functions exported in gnet.h and friends. Using RPCs may work here, or CORBA or any other of those. I don't think we want to code yet another custom remote procedure call interface. The main problem here is wether gui/core communication should happen asynchronously or synchonously. I very much apprechiate that you want to tackle the thing. I fear though, that you started coding without looking at the concepts already in place. -- Richard Eckart <[EMAIL PROTECTED]> ------------------------------------------------------- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com _______________________________________________ Gtk-gnutella-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-devel
