On Fri, Apr 27, 2001 at 02:51:59PM -0500, Brandon wrote:
> > So what you're saying is that if there were a well enforced separation
> > between the protocol message layer and the message passing logic, you
> > could update the former without touching the latter, and you'd magically
> > have a 0.4 compatible node? I must say that I'm a little suspicious
> > of that theory. Is the message passing logic not a central part of the
> > protocol?
>
> No, 0.4 compatibility requires changes in both the wire and behaviour
> aspects of the protocol. However, libfreenet will be kept up to date with
> the wire changes, leaving the maintainers of libfreenet-based nodes to
> only the behaviour aspects of the protocol. I have little faith in
> anyone's ability to keep up to both wire and behaviour changes until I've
> seen them do it because it's more of a pain than you can imagine. I'm not
After trying to figure out exactly WHICH fields of a HandshakeRequest Fred
sets in the 0.3 protocol and to what values, I'd think myself ready for ANY
kind of transitional pain. (I'll be proven wrong, of course. I'll be sure
to vent on the freenet-devl when that comes to pass...)
Perhaps a low-level freenet protocol library is appropriate. I haven't
ever implemented a protocol that way, so I can't denounce the approach out
of experience. It still feels a bit iffy to think that a
"freenet_send_handshakerequest()" function would belong in the low-level
protocol library but that "peer_handle_handshakerequest()" wouldn't.
(the encrypted-transport stuff belongs in the library, obviously.)
> attempting to judge your abilities, just trying to be pragmatic after
> having seen so many projects waste people's time and the fail. If you
> think you can do it, then carry on. I still think you'd be better off in
> the long term outsourcing as much of your project as possible to share
> libraries.
Maybe so.
> > Besides, even libfreenet isn't the magic bullet you're looking for. If the
> > protocol changes drastically enough, every application will have to be
> > re-written no matter how high-level an abstraction you're providing in
> > the library. There's always going to be some rewriting and refactoring
> > when the protocol changes. Personally, I'd like to keep the changes inside
> > a "freenetd" type program on each user's computer, so that the clients
> > would then communicate with the local node using FCP or XML-RPC.
>
> Of course you want clients to communicate via XML-RPC. That's not even an
> issue. The issue is that the over-the-wire protocol will break in 0.4 (not
> as much as 0.3, though) and you'll have to change your code to keep up and
> libfreenet will already be up to date.
Who's afraid of the refactoring bugbear, now? ;-) Personally, I'm more
scared of reading the Java code in Fred. No offense, of course, but the
code is kind of hard to track at times. (this situation is not helped one
bit by the Java custom of grouping source entities by class name instead
of by domain.)
I've had an e-mail conversation with the libfreenet author about these same
things -- perhaps we'll start Cc'ing this list at some point, too.
--
Kalle A. Sandstro"m ksandstr &at& iki &dot& fi
http ohutsuoli 2*viilto www piste iki piste fi viilto mato ksandstr viilto
1ED7 C636: 7728 49D5 F784 D2DD D20F 63CF 655D F19E 1ED7 C636
PGP signature
