Adam Murdoch wrote: >> 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.
For "user mental model" - learning a new model is usually more painful than applying a model you know. And most people are used with JNDI and with the "content + attributes". It is possible to add a wrapper on top of JNDI to provide (or emulate) a different API if you want. There is one particular case that is not very well covered by JNDI - random access to a file. That's where some special extensions or API would be needed. > 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. That is basically wasting the benefits of JNDI... - A well-defined standard for implementing providers. - ability to do caching/replication in a generic way, not specific to VFS ( a JNDI cache can be used for caching LDAP auth results for example ). - built-in event handling, federation, etc. JNDI is an API - i.e. it provides all those things. > 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. The architecture of VFS seems close enough to JNDI - so why not use JNDI as the API ? Something like: - refactor VFS providers to become JNDI providers - create a VFS wrapper on top of JNDI - for backward compat and for people who preffer to use VFS API - all generic tools will be implemented using JNDI - this way they'll be usefull in general JNDI, not only for VFS ( like deep copy of a JNDI tree, replication, caching ). All this can be abolutely standalone components ( if possible with ant wrappers :-) - move the fs and cache from tomcat and merge. The only "framework" that is needed is a set of base classes and utils to simplify the implementation of JNDI drivers. ( i.e. utils ). Costin --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
