Stefan Bodewig wrote, On 04/04/2003 17.55:
On Fri, 04 Apr 2003, Nicola Ken Barozzi <[EMAIL PROTECTED]> wrote:...
Because a URI can be navigated, and it's possible to make a File from a URI.
Not always.
Agreed, not always with the same features. Listing files in a http URL "dir" is not usually possible for instance.
org.apache.tools.vfs.File extends java.io.File
But this version cannot be the argument for the (existing) setters. For this to work, IntrospectionHelper will need to take special care (i.e. if setXYZ(java.io.File) is found, actually pass it an instance of org.apache.tools.vfs.File). This is possible, but ...
* Is this generally desirable?
Yes, this is the question.
<mkdir dir="http://www.apache.org/"/>
<delete> <fileset dir="jar:http://my.server.com/applets/loader.jar";> <include name="**/*.gif"/> </fileset> </delete>
means what?
Delete all gif files that are in the jar at http://my.server.com/applets/loader.jar.
Commons VFS deals with many providers to make this possible, but it's not always possible, as with http that is generally not writeable.
I would have the same problem if a local file was not writeable, it's consistent.
If I sound harsh, please forgive me.
Not at all, don't worry :-)
I'm trying to show that in some situations it may be better to stick with files and we need a way to distinguish them.
Yes, I knew that in many cases this was going to happen. But the above would through an error, as it happens with other non-writeable files. IIUC the main problem WRT this is that URLs are many times not writeable.
* is not as transparent as you say.
Tasks could only use the URI if they first check that the object is is
our version of File and cast to it.
No... that's not how it's supposed to be. What other method do they need?
I can still navigate it, open it, read, sometimes write, all with the java.io.File signature.
I.e. the change in IntrospectionHelper will only work for tasks that can handle it.
Are you sure?
Both points mean that it becomes hard to explain when URIs can get used and when not.
Just as people have by now become so used to the relazive path resolution magic that happens inside Ant that they now report it as a bug if a ceratin attribute is not resolved relative to basedir, we will get bug reports that certain tasks do not deal with URLs of protocol foo properly. I find it hard to imagine that we'll be able to convert all tasks that could reasonably be expected to deal with URIs in one go.
That again I would agree with. I believe that this solution can work *only* if we do not need to change the tasks *at all*. If we need to change the tasks, better using a new attribute.
if I gave you just an url in the constructor, you could write almost, if not all, those methods.
That really depends on the protocol you use. delete() for resources loaded from a jar located on a remote server, loaded via some P2P protocol? I may be making up things, I know.
Yes, I know, but getting real:
1) is that a real use case 2) what makes it not possible or sensible to signal it's not featured?
Am I really missing the obvious? Could as well be.
Same here.
I think we are nailing it now :-)
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------