James Strachan wrote: >> 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?
I think we are all talking about the same thing - from different angles. Both wrappers are needed: - a VFS wrapper on top of a JNDI provider ( like tomcat's, or Sun minimal file provider ) would allow people who want to use the VFS-oriented API, and may absorb differences in attribute namming and support some conventions for random access. - a JNDI wrapper on top of VFS allow people who are familiar with the JNDI API to use it, and allows JNDI tools ( browsers, ant tasks, etc ) to manipulate the VFS. - A JNDI wrapper for VFS providers will allow people to write providers using a simpler API ( and have them exposed as JNDI via the VFS->JNDI wrapper ). - In the same sense, one or several base classes and utils to simplify the creation of JNDI providers are usefull. All JNDI providers would be useable as VFS - just like all VFS providers could be used as JNDI. I think the main point is to make it as easy as possible to create JNDI drivers - and to be able to use drivers from any source. It doesn't matter how JDNI driver is implemented, as long as it follows the spec. What's important is to treat VFS as: - a collection of drivers that can be used by JNDI application - a set of tools to simplify the creation of JNDI drivers for VFS-like systems - a set of APIs to porvide a VFS-centric view of JNDI or VFS drivers. I think we do need a separate component to: - simplify creation of generic JNDI drivers ( like config file abstraction, etc). - implement JNDI drivers for common config files - eventually map to and from jdk1.4 prefs - provide high-level JNDI tools - replication, deep copy, ant tasks, etc. Those will operate on both VFS and any other kind of JDNI ( config, etc ). Remy - are you still on this list :-) ? Costin --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
