> 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. 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. > I am not sacrificing any existing functionality. The changes appear > cosmetic because I made an effort to make the porting pain minimal. Thank you very much. I really appreciate this effort as I hate porting things that already work. > 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. > Let me assure you that after I check this in freenet_request/insert > and fproxy will work exactly as before. Yay! I appreciate that a lot. > 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? > 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. _______________________________________________ Devl mailing list Devl at freenetproject.org http://lists.freenetproject.org/mailman/listinfo/devl
