Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Received-SPF: pass (hermes.apache.org: local policy)
From: Rami Ojares <rami.ojares@elisa.fi>
To: commons-dev@jakarta.apache.org
Subject: Re: [vfs] parsing uri
Date: Wed, 30 Mar 2005 23:16:57 +0200
User-Agent: KMail/1.7.2
References: <DDA88D5CCCFBF44C94C7CDE9D04D55EA5415AF@SEMB001.acc.master.epnet>
In-Reply-To: <DDA88D5CCCFBF44C94C7CDE9D04D55EA5415AF@SEMB001.acc.master.epnet>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200503310016.58279.rami.ojares@elisa.fi>

> Your asumption about the used servers is correct.
> Now why uml or vmware: It is a pain to setup all this stuff and keep it
> in sync with any junit changes.
> With uml or vmware I can provide a image one simply can drop into its
> box and startup the tests.
> So no security problem, just to simplify the installation.

Sounds good.
Vmware is the best IMHO around.
I have used it only their cracked open source so I don't know about
their goodwill to open source dudes :)

> Just as a sidenote:
> I think it is not the responsibility of VFS to ensure running with
> different server implementations.
> The used libraries should handle this. Though, we should do what we can
> to support them finding problems with exotic platforms.

Good point. agree.

> I am not at home now, I will send one later.

Take your time. I don't pay anything for this :)

> Tempfs uses the DefaultFileReplicator to handle its content.

So where are the files stored? Do they get deleted when vfs closes.
Or when jvm closes? what if jvm crashes?

> >- url provider bothers me because it kind of duplicates vfs. And it
> > DUPLICATES the effort of vfs (http, ftp, jar ...)
>
> Now you get emotional ;-)
> Its better to integrate than to rule out.
> We also provide a method to wrap VFS into a URLConnection.

I was not emotional. I was rational. Now that I have been sipping some italian 
red wine I am ready to get emotional.
What do you mean by integration?
Integrate into what?
The point is that it does not offer any capabilities that are not already 
provided by vfs. So i does not give any further integrative possibilities.
What it does give is undocumented features that duplicate documented features.
And it does not work (probably) with all implementations of Java API.
And the whole project of accessing any urls with some api (like the 
URLConnection API) is doomed to fail because url is such a broad concept and 
there will be cases of url that fit VERY badly to the API.
I mean you can point to anything with URL (that is where the universal comes 
from). And you can not have a meaningful api to ANYTHING. URIs and URLs are 
about universal naming in the world of computers (and internet specifically).
Api's tend to go beyond naming. 

Further this "let's embrace everything" attitude will take vfs into the world 
of yet another universal whatever. And the evolution is like this. A lot of 
good things and features are provided that are trendy at the moment. When the 
system becomes too messy to understans it is forgotten.

Virtual filesystem can mean anything because of the magic word virtual.
But I wish this would be just a filesystem that can integrate different kinds 
of filesystems on the network. That already is a tall order. And also note 
that filesystem model is very simple hierarchical model. So we should not see 
it as the ultimate way to model and interact with data.

I think I am still being rational but in a good emotianal way :)

- rami

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org