On Wed, Apr 04, 2001 at 01:46:51AM -0400, Gianni Johansson wrote: > On Wednesday 04 April 2001 00:18, you wrote: > > I have some revamps to the API which are about ready to commit. > > The purpose is to modularize things to allow pluggable metadata handling > > What is pluggable metadata handling???
Basically for any request you can specify what kind of automatic metadata handling you want, or none. This is to provide support in the freenet.jar for Redirect, SplitFile, etc. > > and pluggable backends (FNP, FCP, InternalClient, whatever). > Can you really do this without sacraficing the rich functionality provided > by the current Client implementation? Yes. > > This will break anything depending on Client. > > ! > > I have a lot of working code that uses the current Client API and > depends on the semantics of ClientEvents. Porting it is *very* simple. Breaking it was necessary because we must provide an FCP implementation yet we cannot just throw away the FNP implementation at this point. The old way wasn't suited for more than one backing implementation. > > but the adaptions to make > > are minimal. I have ported RequestClient, InsertClient, and > > SimplifiedClient, so only outside packages will be affected. > > > > The old way of using Client looked like: > > > > Client bc = new Client(clientCore, targetAddress); > > ClientKey ck = ClientUtil.getKey(uriString, params); > > RequestToken rt = bc.prepare(htl, ck, dataBucket, metaBucket); > > ... add listeners with rt.addEventListener() ... > > bc.makeRequest(rt); > > ... synchronized on a listener and wait for events ... > > > > The new way: > > > > String uri; > > ClientFactory cf = new FNPClient(clientCore, targetAddress); > > DataRequest req = new DataRequest(htl, uriString, metaBucket, > > dataBucket); ... add listeners with req.addEventListener(); ... > > Client c = cf.obtainClient(req); > > c.execute(); > > ... synchronized on a listener and wait for events ... > > > > The current list of Request types: > > DataRequest, InsertRequest, > > HandshakeRequest, ComputeCHKRequest, ComputeSVKRequest > > > > As of now the last 3 are only relevant to FCP. SimplifiedClient and the > > CLI clients should probably start making use of the last two. > > > > I haven't figured out how the pluggable metadata handling is going to work > > yet.. it will involve something like a Handler class and several subclasses > > (RedirectHandler, SplitFileHandler, etc.), where the desired handlers are > > registered with the Request or the Client and the rest is automatic. > This sounds suspect to me. The final decision of how to interpret metadata > belongs with the application writer, not the Client library implementor. Of course it does. The intent is to provide standard metadata handlers for the standard metadata standard ;'P .. use of them will be optional. > > > > TODO: > > Handler framework > > FCPClient > > possibly InternalClient > > > > What about ClientEvents? I didn't change the event framework at all. You just add your listeners to the Request object instead of the RequestToken. > This "... synchronized on a listener and wait for events ..." makes me > nervous. Sounds like the same (limited) assumptions that led to the design of > SimplifiedClient... Can you really supply the rich functionality > currently provided by ClientEvents? I didn't change it at all. -- # 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
