"Kalle A. Sandstr\"om" <[EMAIL PROTECTED]> writes:
> > Yeah, it definitely does need some clean-up. I've got an enormous
> > list, and I'm working on it.
>
> Is that a long list of small things or a small list of large things?-)
>
> Anyway, mind passing the list my way? Maybe I could fix some of the
> things while fleshing out the libfreenet integration.
It's both a long list of small things and a short list of large
things. The most significant of those things are in the "TODO" file
that comes with libfreenet. The largest thing on the list is "use
dynamic memory allocation", which I totally ignored in the interest of
stabilizing the library before I went and introduced a shitload of
potential leaks.
> Many functions aren't prefixed (inappropriate for a potentially shared
> library).
Yeah, I should have done that a long time ago. All of the exposed API
functions are prefixed. I'll be sure to get around to prefixing the
rest of them, unless you feel like having some search-and-replace fun
yourself.
> The "freenet_get_connection" fn is too one-shot (a proper node would
> have a thread run an accept(2) loop and pass the connected socket
> fds to a peer handler).
Agreed. In fact, my development version of testserver includes an
accept(2) loop already. freenet_get_connection is still useful
internally.
> Also, glib has a nice stdout/stderr/logging abstraction which should
> make things easier for a node that runs as a UNIX daemon (i.e. the
> node could install its own log handlers into glib and push the
> output into a log file instead of a stdout connected to /dev/null).
I don't think this kind of thing is appropriate internal to a library.
Does my library have to support glib for you to use it for logging?
> There's also a pretty nice mutual exclusion thingy in the glib
> thread module, that would remove the need to code for POSIX threads
> if libfreenet ever requires explicit threading support
> (gethostbyname(3), anybody?).
Threading does not belong in a unix library. My goal is to write a
threadsafe API, and let users worry about whether they want to thread
or fork() or select().
> My 'message_t' design was pretty far a reimplementation of the
> simple HTTP server class I did in C++ a couple of weeks ago. That
> one used a std::hash_map<std::string, std::string> to keep both the
> request and reply headers in a request structure, which was then
> passed on to a virtual function that was supposed to handle the
> request. The design worked pretty well (apart from the fact that it
> allocated a pile of memory chunks for each request) and I decided to
> use a same kind of 'fields in a mapping' approach for this.
That sounds like it might be a good thing.
> The 'cipherstream_t' stuff was designed to use a separate 'cipher_t'
> block cipher encapsulation because I wanted to be able to switch
> between Rijndael and Twofish cleanly, perhaps supporting other types
> of encryption in the future. The result is a bit C++-ish, only in
> C.
I think libfreenet already has something like this.
-S
_______________________________________________
Devl mailing list
[EMAIL PROTECTED]
http://lists.freenetproject.org/mailman/listinfo/devl
