Hi everyone,
I finally decided to tackle the gui/core seperation idea a few days ago.
I'm sure when I'm done what I can do, someone more knowledgable about
interfaces and longevity of projects can tweak it and polish it a bit
but hopefully I'll have done most of the grunt work. In fact, I think
I've done most of the work already. 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's four sets
of files really, "gui", "core", "interface", and "common
libraries" (routines that gui and core can share). Now I want to
abstract the actual interface to the interface and we should be in a
pretty good place. (when I submit the diff I'll write up a more
detailed description of what I've done/discovered going through this.)
Once I'm done, I'm expecting that it will need to be modified.
Especially because I'm not so much saying "this is the interface we
should use" and then making the code fit the interface. I'm instead
just keeping basically all the functionality and implementation we have
and saying "this is what we've been doing, but in a more seperate and
easier to see way". Untangling the spaghetti so to speak. Once we're
there we can see what changes need to made (I can already see lots that
we'll have to address) and hopefully will be able to do them.
Anyway, enough banter, I have 3 questions for y'all that will help me
lots.
1. Most of this work was digging through long chains of buried
dependencies. I have to do a final check to make sure I haven't missed
any before doing the abstraction stuff. I only ran into 1 problem:
file.h/c depends on ban.h. This is only for one function call. What
happens in file.c is when we try to get a new file descriptor and it
fails, we try to grab a file descriptor that we have been using for
keeping banning lists or something (I don't know the details of ban.c).
The problem is ban.c depends on about half of the core so cannot be
included in the common libraries (ie. the gui can't include it without
depending on core files). I see two solutions, maybe you have other
ideas.
a) remove the functionality. Dismiss it as a rare case (I don't know if
it is) and just remove the dependency. For now this is what I've done
(I just commented out and notated the function call with a FIXME).
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.
2. I haven't yet done the property tables, this is what I'm going to do
next (before the abstraction). My idea is to provide interface
functions so that the gui can get/set gnet properties and the core can
get/set gui properties using a string identifier. So the gui could say
gui_core_interface_get_gnet_property_guint32("PROP_WHATEVER"). As of
now we just use "#define"'s. I'm planning on using GLib Keyed Data
Lists/Quarks. I don't really anticipate any unusual problems but I
wanted to mention it in case those of you with more experience saw an
obvious problem with this or a better solution.
3. I have never done "function pointers" etc. in C except for some
hacked-up cutting and pasting. Does anyone know what the best way to,
say, given the string name of a function to be able to call that
function? So the gui could do something like
"gui_core_interface_call_core_function( "download_new", [parameter
list])"
Okay thanks for the help!
Emilie
-------------------------------------------------------
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
