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??? > and pluggable backends (FNP, FCP, InternalClient, whatever). Can you really do this without sacraficing the rich functionality provided by the current Client implementation? > 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. > 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. > > TODO: > Handler framework > FCPClient > possibly InternalClient > What about ClientEvents? 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? --gj > .... > > There are also some bug fixes to FCPHandler and it has been brought up to > date with the spec. > > P.S. is there any reason not to use an int for HTL instead of a long? -- Web page inside Freenet: freenet:MSK at SSK@enI8YFo3gj8UVh-Au0HpKMftf6QQAgE/homepage// _______________________________________________ Devl mailing list Devl at freenetproject.org http://lists.freenetproject.org/mailman/listinfo/devl
