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. The only reason to chose a different API if you _implement_ a VFS is the extra complexity ( JNDI does a pretty good job at keeping simple things simple for _user_ ). However in the long run, the many small details that JNDI covers and VFS doesn't might matter - I'm talking about security, the very tricky isolation on class loaders ( java:comp ), federation, optimizations ( caching, avoiding GC, etc ). Costin --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
