ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam Murdoch" <>
Subject RE: Virtual FileSystem Layer
Date Fri, 28 Dec 2001 23:47:41 GMT

> From: Stefan Bodewig []
> 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 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.


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message