On Mon, 19 Feb 2001, Brandon wrote: > > 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?
I've implemented a few, but haven't reverse engineered anything. Just this morning I implemented my variation of the LocalServ protocol in my new client and modified my Whiterose to support it. The thing is, what we need to do is so totally simple that there's no good reason not to write the protocol ourselves. > > 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. Yeah, that and metadata aren't possible with FProxy, unless you hacked HTTP to append the metadata after the Content-length says the data should be over (untested, of course) and wrote headers out as the status progressed. > 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. Yep. That's the reason why having a client protocol is a good idea, of course. > 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. Any examples? > 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. I have some problems with their proposal. Sure, it's robust, but it's also more complicated. I agree, I prefer an existing protocol to theirs. My advocacy of writing our own only holds if it's really simple, like LocalServ. Otherwise we're better off with an existing protocol, even if it's somewhat bloated. -- Mark Roberts mjr at statesmean.com _______________________________________________ Devl mailing list Devl at freenetproject.org http://www.uprizer.com/mailman/listinfo/devl
