> From: Stefan Bodewig [mailto:[EMAIL PROTECTED] > > Any estimate how bad the performance of JNDI compared to direct file > access is? Can we implement a hybrid solution that uses direct file > system access when we know that we are talking about plain local > files? >
This is a good idea. Probably the best way to deal with this kind of issue is to put together our own VFS API, and layer it on top of the file system providers (e.g. JNDI in this case). This gives us the flexibility to use JNDI whilst prototyping the VFS, and add in a direct file provider once it stabilises (though, I would probably do it the other way round - start with direct file access and add JNDI later). Granted, we don't know whether JNDI performance is an issue or not. However, technologies like JNDI (or java.io.File for that matter) almost always require an app to compensate for bugs, performance problems, or missing bits of functionality. This is especially likely in ant's case, given how heavily dependent the tasks are on the file system (almost every task touches the file system - and there are an awful lot of tasks), and the range of platforms (OS/JVM) that Ant is used on. Having a single spot to deal with these issues is far better than having them dealt with in every task (inconsistently dealt with, of course). An added bonus of using our own API is, we end up with an API that does what the task writers actually need. Having a good semantic match means simpler task implementations, more consistent behaviour, and less "how do i .." questions. The file system is by far the most heavily used service in the current set of tasks. There are a huge number of tasks, both built-in and custom, and an equally large number of task developers. Making the file system as easy to use as possible should be the primary motivation of the VFS. Even if the implementation was limited to local files only, it would still be a huge win. Of course, there's only one way to know whether an API is useable or not, and that is to write code against it. So, I'd like to do up a prototype of an API that a task writer might use to get at the file system. This will let us compare writing tasks against a custom API, and a JDNI based API (of course, the custom API may well sit on top of JNDI). Probably another useful thing for us to do is decide on a model for the file system - that is, what is a "file"? what do they contain? how are they structured? how are they named? what operations can be performed on them? Here's a starting point: - A file may have content, which is simply a chunk of binary data, plus some attributes that describe the content: - MIME type - size - encoding - last modified timestamp - etc. - Files are arranged hierarchically - that is, a file has a single parent. - A file can either have content or child files, but not both. - A file is identified by a URI (including relative name + base URI). - A file has some attributes: - access control info - etc - Operations on a file: - create. - delete (including all child files). - move to a new parent, rename, or both. - get or set attributes. - Operations on a file's content: - read or write as a stream only (no random access). - get or set attributes. I don't think we need anything more detailed than that. Adam -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
