> 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 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. > 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. _______________________________________________ Devl mailing list Devl at freenetproject.org http://lists.freenetproject.org/mailman/listinfo/devl
