Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
From: Adam Murdoch <adammurdoch@apache.org>
To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Subject: Re: VFS and JNDI
Date: Thu, 27 Feb 2003 10:16:12 +0000
User-Agent: KMail/1.5
References: <3E5C23C4.8040501@hanaden.com> <b3i44t$len$2@main.gmane.org>
 <b3ingj$aa8$1@main.gmane.org>
In-Reply-To: <b3ingj$aa8$1@main.gmane.org>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200302271016.12649.adammurdoch@apache.org>

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.


-- 
Adam

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org