commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Strachan" <>
Subject Re: VFS and JNDI
Date Thu, 27 Feb 2003 08:11:05 GMT
From: "Adam Murdoch" <>
> 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
> > >> 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
> > >> model (get content as a stream, content signing, copy a tree,
> > >> to/from, etc), and does things in a way that reflects
> > >> 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
> 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
> 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
> What I'd like to do is see if we can support both.  There's a few
> 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
> services like caching, replication, event handling, federation, and so on.
> - Sit the framework on top of the providers, using a custom provider API
> 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
> the JDNI adapter.  The goal is to minimise the layering between the
> and the user API (be that JNDI or VFS), rather than sitting one API on top
> 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
> 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?


Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message