> It's superior if you want to write Freenet libraries in scripting > languages that make it hard to implement something like LocalServ. But for > C, C++, and Java, it only makes things harder, IMHO.
Erm...well, I'm going to have to say that making some calls to an already existing library is almost always easier than writing a library based on reversing engineering another implementation because the protocol documention is out of date. Even in an idealistic world where the protocol documentation is correct and complete, I would say that making some calls to an already existing library is almost always easier than implementing a protocol yourself. Do you have much experience implementing and reverse engineering protocols? > Most clients will use a Freenet library that handles higher-level stuff > like redirects automatically, and will never even see any XML. But if you > think that implementing client libraries in weird scripting languages is > important, then using a standard protocol is a good choice. You seem to think that I've got some crazy ideals that I'm attempting to apply inappropriately to the real world whereas I'm really just speaking from my experience with the various Freenet client projects which have died. It's not about weird scripting languages, it's about making it easy for the people doing real Freenet projects to do things. There has been Freenet code in Java, Python, C, C++, and VB. There are all reasonable languages to want to code stuff in. Everybody wants to be able to talk to the Freenet node is as few lines of code as possible but they want to be able to get back status information and such so they don't want to use FProxy, which is in fact one implementation of a client protocol. So you can implement a client protocol library in Java, Python, C, C++, and VB. This is vastly preferable to the old idea, which was that you should write an FNP library in Java, Python, C, C++, and VB. It still seems easier to me to use a library that already exists rather than to write your own. All of these languages have libraries for XML-RPC, SOAP, and CORBA, so in terms of programming ease any of these choices is less work than inventing a client protocol. Additionally, there are already a lot of programs out there that speak these protocols. If Freenet spoke one of these, a lot of programs would already know how to talk to it without any modification. But, you know, whatever. If Scott, Oskar, and Adam have all agreed on a client protocol then I'm wasting my time with this discussion. I can always write an XML-RPC service and client writers can take their pick. _______________________________________________ Devl mailing list Devl at freenetproject.org http://www.uprizer.com/mailman/listinfo/devl
