On Wed, Apr 04, 2001 at 05:47:08AM -0500, Brandon wrote: > > So yes, better interface, major maintainability improvement. > > For example, the notion of a "Request" is now separate from the specific > > client implementation used to make it happen. So setting up your > > requests and what types of automated metadata handling you want will > > be independent of the client backend. > > > > Right now that kind of thing is hardcoded into Client, InsertClient, > > RequestClient, and SimplifiedClient. > > Client should not do automated metadata handling. Ever. InsertClient and > RequestClient should have everything hardcoded because they are examples > of how to use the Client API and should have everthing out of the hood so > you can see it. Automated metadata handling should be hardcoded into > SimplifiedClient because its purpose is merely to provide "reasonable > defaults" for how to handle metadata "i.e. redirect on redirects". You can > turn SimplifiedClient's automated metadata handling off, of course.
I do agree though that Client itself shouldn't do automated metadata handling. Client is just for executing requests. The idea is that you can specify desired types of automated metadata handling and have Client instances fired up for you to take care of the necessary chain of requests, *if you want*. Otherwise you just use Client without any metadata handling. SimplifiedClient then would just opt for all of the standard automated metadata handlers. Good OO is to separate code into logical units. The idea of metadata handling can be dealt with purely in terms of Requests without knowing anything about the Client backend. Therefore hardcoded metadata handling does not belong in Client, InsertClient, RequestClient, or SimplifiedClient. Following your suggestion would limit flexibility. > So the only place it's not hardcoded is in user's own client code, in > which case they have to write their own code themselves. Having a > particular standard API for writing metadata handlers would be > nice. It seems pretty silly to handle them in the Client library, > though. You just fetch a file, check to see if it's metadata, and then if > it is you launch your client-specific code to handle it. > > > After this change we can build the rest of the enhancements as > > plug-ins without further impacting existing, working code. > > If you wrote InsertClient and RequestClient to use SimplifiedClient then > the only place in which you'd be doing this is in SimplifiedClient and in > user client code. I don't see how a plugin architecture is better than > doing an if elseif block on the control document type (Redirect, etc.). > > A plugin architecture is useful when you're going to be writing > alternatives that you may want to switch out, which isn't the case here. Wanna bet? Read the new metadata standard... think it's not going to get more complex later? Will every client will always want to do either every kind of automatic handling specified in the standard, or none of them? > > I'm not changing the FCP servlet (well, except for the mentioned fixes). > > The goal is to provide an FCP *client* and a good framework for metadata > > handling that isn't rigid and difficult to expand like the current way. > > I don't think it's difficult to expand. Rigid is fine. We're not > hot-swapping metadata handlers. We write canonical versions of metadata > handlers for SimplifiedClient and paste the code into RequestClient. If > you want your own handler, turn off the default one and implement your > own. Our system already does this fine. What does the new system actually > change? Well the new system is open to design at this point, but I think we do need something that allows "hot-swapping metadata handlers." It's not hard to imagine a client that may execute a complex series of requests and desire different automated handling for different ones. > > I'm really barely changing anything at all. I'm just adding an interface > > (ClientFactory) which FNPClient implements, instead of having only Client, > > and I'm abstracting the information about the Request into a class that's > > independent of which ClientFactory implementation you use. > > Having multiple Client implementations is *totally* *wonderful*. It's the > pluggable metadata handlers that seem like a non-feature. We'll see ;^) .. I don't have any _working_ code for the metadata part yet -- # tavin cole # if code is law, then Freenet is a crowded theater _______________________________________________ Devl mailing list Devl at freenetproject.org http://lists.freenetproject.org/mailman/listinfo/devl
