Lads, Would you be prepared to let me loose on it? I can do a nice job of it, and you're welcome to inspect my code before I check it back in. If you could decide now it would be good, because my evening is just beginning.
Oskar - perhaps you could check in what you have. Steve On Tue, 8 Aug 2000, Oskar Sandberg wrote: > > 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 > _______________________________________________ Freenet-dev mailing list Freenet-dev at lists.sourceforge.net http://lists.sourceforge.net/mailman/listinfo/freenet-dev
