I'm sorry Brandon, but I have to agree with Scott on this point. The code in the clients was unmodular and linear before, but the only thing that pulling it apart and leaving the code in a dozen different methods scattered throughout the classes in no logical order (and with zero javadocs, and what does not seem like a planned interface) calling eachother left and right did was turn it into unmodular spaghetti.
If we want the code to be useable as client library, then we need to carefully consider what interface we want for the people accessing the client objects. Ian's recommendation that we javadoc first, implement second, could not be more correct in this case. I rewrote the ClientCore and ClientMessageHandler Sunday so that it can handle replies from several chains at the same time. It does this by queueing recieved replies by their id number, and having a getNextReply(id) method that returns any reply in the queue or locks and waits for one. This finally get's rid of the aweful sleep/interrupt code that I wrote as a temporary hack way back when. This also means that a graphical client which will do many requests does not need to restart the whole ClientCore for every request sent (and that it can do several at the same time). I have not committed this code yet, because the existing code is so scattered that when I actually managed to track down where it get's replies, it turned out that it didn't have the chain id in several places (and I don't like just throwing on another variable to the interface just like that). I will try to do emergency surgery to get it in today. So a larger client using these classes as a library to do requests will want to be able to generate new Request/Insert objects, based on a ClientCore (I added a static method the ClientCore that returns a tcp and FreenetProtocol based Core - people shouldn't have to bother with our transport/connection abstractions), a set of Params, and then be able to do inserts and requests from a Keyword value/Public key (for SVKs), and a file (or possibly a stream, though that is difficult to handle with the restarts and alike). Things like constructing the client based on a string of args (how to parse them is _completely_ to do with the one CLI based implementation, not the library) or a bunch of Freenet specific classes like Address, Transport and ListeningAddress are both equally wrong for somebody trying write a client that calls this. An amazingly confusing interface with zero planning and no javadocs is just trying to screw with them. On Tue, 08 Aug 2000, Brandon wrote: > > Honestly, looking at Old* vs new *, the only real differences I could see > > was that all the existing code was moved around. I think a real rewrite > > might be in order. > > Before it was a single main function. Now it is broken down into > overridable functions so that it can be subclassed by other clients. Which > means I just moved code around. An area where significant work could be > done is in how the client handles messages that it receives. Structuring > of client message handling is on my TODO for when I have more time (i.e. 3 > weeks, when I quit my job). My focus up to this point has been converting > the client classes into a reusable client library. Another pass could be > done on this, stripping out the CLI parts of the code into a separate > subclass for CLI clients. This code isn't useful on Mac clients, for > instance, which can't take command-line arguments, or Windows clients, > which just don't. > > > * No need to have asynchronous behaviour in the cients. Thats causing a > > lot of bugs or at least inconveniences. > > Yes, asynchronous behaviour definitely makes things more complicated. I > don't know about there not being a need, however. You might want to be > requesting multiple things at once. Of course, the client could open up a > new connection in a new thread for each request. That's how I'd prefer to > do it, but I'm not sure if it's the best way. > > > > * The code should be re-entrant. It should be very straighforward to > > listen for an additional message on an existing connection. Currently > > the clients are very 'one-shot' in nature. > > True. So you think that the connection should stay open and send more > messages instead of closing the connection and opening a new one for the > new message thread? > > > > _______________________________________________ > Freenet-dev mailing list > Freenet-dev at lists.sourceforge.net > http://lists.sourceforge.net/mailman/listinfo/freenet-dev -- \oskar _______________________________________________ Freenet-dev mailing list Freenet-dev at lists.sourceforge.net http://lists.sourceforge.net/mailman/listinfo/freenet-dev
