Mailing-List: contact commons-user-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Users List" <commons-user@jakarta.apache.org>
Received-SPF: pass (hermes.apache.org: local policy)
Message-ID: <42A457FF.2000508@sophia.inria.fr>
Date: Mon, 06 Jun 2005 16:04:47 +0200
From: Philippe Poulard <Philippe.Poulard@sophia.inria.fr>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041220
MIME-Version: 1.0
To: Jakarta Commons Users List <commons-user@jakarta.apache.org>
Subject: Re: [VFS]  VFS.getManager().getFilesCache() - exists() vs findFiles()
References: <20050518225313.30303.qmail@web31512.mail.mud.yahoo.com>
 <428C2457.9090504@ops.co.at> <428C8D71.3080008@ascii27.net>
 <428CC1C4.80206@ops.co.at> <429DE963.1050706@sophia.inria.fr>
 <429DF548.8040706@ops.co.at> <429ED24B.4050800@sophia.inria.fr>
 <429EE996.5070409@ops.co.at> <429F1F2D.1040504@sophia.inria.fr>
 <42A00594.3080505@ops.co.at> <42A03C76.9070806@sophia.inria.fr>
 <42A04771.5040104@ops.co.at> <42A051D5.4090905@sophia.inria.fr>
 <42A1527C.7020007@ops.co.at>
In-Reply-To: <42A1527C.7020007@ops.co.at>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Mario Ivankovits wrote:
> Philippe Poulard wrote:
> 
>> xmldbRaweb2004:xyl://user:pwd@www.foo.com/path/to/file.xml
>> ^^^^^^^^^^^^^^
>>    this is not the xmldb scheme, as recommended by XML:DB
> 
> I didnt mean to rename the provider, but to provide a mechanism where 
> one can tie a set of FileSystemOptions to a specific provider.
> However, there is also another way to solve this. You can pass the 
> FileSystemOptions to the resolveFile method.
> 
> FileObject fo = FileSystemManager.resolveFile(String name, 
> FileSystemOptions fileSystemOptions)
> Any subsequent call to "fo" (e.g. FileObject.resolveFile) will be able 
> to access these options.
> 
>>> What if we create a new method "FileObject.createFile(Map attributes)"?
>>> That way there is no need to change the contract of the IMAGINARY 
>>> file type and it makes clear that if you would like to create a new 
>>> file with special attributes you have to call that method.
>>
>> in this case, because of the particularity of all this stuff, it will 
>> be more suitable to override the getAttributes() method (or another, i 
>> will look the code) to perform the operation without checking the file 
>> type
> 
> The best is to find a clean solution. The http filesystem might also 
> profit from it as it might be needet to send the content-type of a file 
> to the sever.
> 
> The problem with the solution to allow IMAGINARY Files to have 
> attributes is the setAttribute Method. Its passed down to
> AbstractFileObject.doSetAttribute(final String atttrName, final Object 
> value)
> which might immediately access the filesystem. But with IMAGNIARY files 
> there is no file where the filesystem can attach those attribute then.
> 
> So why is it that bad to have a "FileObject.createFile/Folder(Map 
> attributes)" isnt it a clean entry point to create a File/Folder with 
> specific attributes?
> Afterwards one can use setAttribute/getAttribute to modify them (if 
> possible)

ok, that's clean

thanks

> 
> Also its needet to separate the attributes into FileSystemAttributes and 
> FileAttributes.
> You might not see any difference when you use your active tags. But 
> there are differences if you use VFS in your code.
> 
> *) You have to pass the FileSystemAttributes only to the first resolveFile.
> *) With every different set of FileSystemAttributes VFS will create a 
> new FileSystem. So if you access two clusters VFS internally maintains 
> two filesytems.
> 
> xmldb:xyl://user:pwd@www.foo.com/path/to/file.xml with cluster=Raweb2004 
> is different to
> xmldb:xyl://user:pwd@www.foo.com/path/to/file.xml with cluster=Raweb1998
> 

this solution doesn't suit to Xyleme, because the idea of cluster is 
somewhat unusual : you need it when you store a file, but you may omit 
it when you retrieve it !

-- 
Cordialement,

            ///
           (. .)
  -----ooO--(_)--Ooo-----
|   Philippe Poulard    |
  -----------------------

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