From: "Adam Murdoch" <[EMAIL PROTECTED]> > On Wed, 26 Feb 2003 03:33 pm, Costin Manolache wrote: > > Nicola Ken Barozzi wrote: > > >> They are very similar. JNDI is a little more general: a namespace of > > >> Objects. VFS is a little more specific: a hierarchy of files. > > >> > > >> VFS does not try to be as universal as JNDI does, even though there is > > >> going to be plenty of overlap (find by name, create, delete, get/set > > >> attribute, > > >> etc). VFS adds things that don't make sense under JNDI's more general > > >> model (get content as a stream, content signing, copy a tree, converting > > >> to/from java.io.File, etc), and does things in a way that reflects how > > >> files get used (as opposed to how generic namespaces of Objects get > > >> used). > > > > > > And many don't want JNDI just to use VFS, just like we use io.File. > > > But I agree that a JNDI wrapper to VFS would be very cool. > > > > JNDI is bundled with JDK1.3+ and is available to JDK1.1. It is well > > documented ( books, etc ), required ( or strongly supported ) in Servlet > > environments. I could say it is ubiquous. I can hardly see any reason > > why someone would use a different API to use a VFS. > > For the same reason you'd use a different API for anything: a better fit for > the task, and a model that is a better match for the user's mental model. > It's argueable whether the current VFS API achieves this over JNDI. It > largely comes down to personal preference, I think. I certainly prefer the > VFS API to JNDI for file access. But I can understand how others would > prefer to use JNDI. And I can picture cases where I'd rather use JNDI too. > > What I'd like to do is see if we can support both. There's a few approaches > we could take. My preferred option is to do the interoperability at the > provider level. Something like this: > > - Move the provider agnostic stuff into a core framework. This would provide > services like caching, replication, event handling, federation, and so on. > - Sit the framework on top of the providers, using a custom provider API (not > the JNDI provider API). > - Sit the VFS API on top of the framework. > - Sit a JDNI provider adapter on top of the framework. > > This pretty much reflects the current VFS architecture - the missing piece is > the JDNI adapter. The goal is to minimise the layering between the providers > and the user API (be that JNDI or VFS), rather than sitting one API on top of > the other. I think with a bit of reorganising, we can end up with a > reasonably performant VFS for both APIs. I'd be willing to bias performance > in favour of JNDI, if that were necessary.
This sounds good. Just a thought about another idea; what if VFS also provided an optional JNDI-extension interface. i.e. provide an API on top of JNDI's Context / DirContext so that the VFS-like API can be used or the underlying JNDI API all from the same objects. Or to put that another way, would implementing Context & DirContext & Name as part of the VFS API be a good thing? James ------- http://radio.weblogs.com/0112098/ __________________________________________________ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
