Hi! I have to leave right away so I'm afraid this will be briefer than it should be but I should off and on IRC for the next few days. I'm looking forward to more discussion there. The problem is, when I'm on IRC (around midnight, 1am) you europeans are sitting at work in the sun at 10am :)
Jeoreon: I looked at the API you sent, I thought it looked great. The truth is I didn't actually know how to implement something like that. It seemed to me what I'm doing is the first step for something like that anyway and, at least, I think it will make it far easier to implement an API like yous. On Wed, 2004-07-07 at 22:36 +0200, Richard Eckart wrote: > When I worked on the separation, I identified three different > "sections". Core, gui and common (shared code). What is "interface" for? I think eventually we should seperate the program into two processes that can compile independently (at least that's where my brain is going). So we can't have the gui including core files all over the place, hence the need for an interface. Even if we don't split the process, the way it is right now, any gui function can (and does) call any core function. The way I'm rewriting things, the gui has no core includes at all (and vice versa) and if it needs to call a core function it has to use an interface function. So in the interface file there are 5 or 6 (or however many) "fileinfo" functions that are, right now, basically just redirects for the regular functions in fileinfo.c. This means we can easily see and define the way the gui can affect the 'fileinfo' part of the core (how c++ of me:). Obviously *what* we want to do with the interface is the crux of the seperation problem and what we have to figure out. The way the main code is right now, everything is dependent on everything else in this giant mess of "wires". You'll see when I'm done how deep some of the dependencies are. Even if we decide not to use an "interface", etc. the side benefit of this is that the dependencies have been cleaned up a lot as I've gone along. For example, a gui file includes "misc.h" so it can use the RCSID function. Well you follow the dependencies, and with the file.h problem I mentioned before we find that by including "misc.h" we are also including download.h plus most of the rest of the core. This type of thing should be greatly cleaned up. Oh yeah, about the properties. In the gui and core I wasn't planning on changing the autogen files or the way the props are defined or anything for now (I really think we might have to someday soon... then again I'm a c++, php, etc. person: I cringe when I see #define). I just need a way for the gui to be able to see core properties without needing to include like half the core. I don't see a nice way to do that aside from a map or hash (ie. string to property map). > 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. :) The events, callbacks, etc. are sort of beyond me. I tried to look at that and the API that was on the table, the way the code was structured, etc. and to do what I thought needed to be done and to make sure it was easy to modify and change so my ideas would be tempered by the rest of y'all. If it turns out that what I've done is not the direction gtk-gnutella is going then I'll just make a fork called emile-gnutella. Just kidding, then it's fine, I'll throw it out. So I spent a few days and learned the codebase pretty throughly. No big deal. I am going to try to do the string/property maps and double check the dependency lists in the next 2 or 3 days. Then I'll send it in. We'll see where all my ideas stand then! ok, i have to go, talk to you all later, e ------------------------------------------------------- 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
