You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Yannick Menager <ym...@yahoo.co.uk> on 2005/12/08 19:16:32 UTC
[VFS] Contributions to the project
Hello,
For quite some time, i've been thinking about using a 'virtual
filesystem' kind of GUI to some application that i'm working on.
Recently i've decide to dedicate some time on it, and since VFS seems to
fullfill some of my requirements, i was thinking of extending it, and
contributing back my work to the project for integration, if that is
found to be desirable.
Now, here's a quick overview of changes and additions that i'm planning
to work on, and i would like for you guys to tell me your opinions, and
if you feel those are things you'd wants integrated in VFS, or would
prefer to keep separate.
1) Cache API.
The addition of the following APIs to FileObject ( or alternatively, a
new Interface CacheFileObject that would extends FileObject ).
/**
* Determines if this FileObject uses cached data.
* @return True if this object's data is provided by a cache.
* @since 1.1
*/
public boolean isCached();
/**
* Refreshes this object's cache.
* This won't do anything if no cache is been used, or if a cache
refresh is already ongoing.
* @throws FileSystemException If an error occured while refreshing
the cache.
* @see #isCached()
* @since 1.1
*/
public void refreshCache() throws FileSystemException;
/**
* Determines if this object's cache is in the process of being
refreshed.
* @return True if cache a cache refresh for this object operation
is occuring.
* @see #refreshCache()
* @since 1.1
*/
public boolean isRefreshingCache();
/**
* Waits for an cache refresh operation on this object to finish, if
one is currently ongoing.
* This will return immediately is no cache refresh is currently
ongoing.
* @throws InterruptedException if another thread interrupted the
current thread before or while the current
* thread was waiting.
* @since 1.1
*/
public void waitCacheRefreshed() throws InterruptedException;
/**
* Waits for an cache refresh operation on this object to finish, if
one is currently ongoing.
* This will return immediately is no cache refresh is currently
ongoing.
* @param millis the maximum time to wait in milliseconds.
* @throws InterruptedException if another thread interrupted the
current thread before or while the current
* thread was waiting.
* @since 1.1
*/
public void waitCacheRefreshed( long millis ) throws
InterruptedException;
2) VFS Browser
An windows explorer type panel to browse a VFS
3) File Actions
Ok, that's where things get a bit more tricky. What i was thinking, is
to allow the files to provide a generic way of providing information of
what kind of actions can be performed on it.
The idea is something along those lines:
A file can have a number of Actions (interface), each of which have a
name, a description, and potential arguments types to be used in
execution.
The action contains an execute method, that can be given a map of
ArgumentTypes / values.
I'll send more on this later on...
Yours truly
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [VFS] handling of broken links
Posted by fi...@cirquedigital.com.
> Hi!
>> Anybody any ideas of how to resolve this ? I'm guessing that
>> it should either be a FileType.LINK or a regular FileType.FILE
>> and that exists() should return true, but that when accessing
>> the content an exception needs to be thrown.
>>
> Sometimes I think VFS still do a little bit too much on its own logic.
>
> What if we keep the current behaviour but access the filesystem layer
> even if the file is not existent? (From VFSs point of view).
> Hmmm ... or your FileType.LINK ... I am not sure.
I think the FileType.LINK is probably opening a can of worms..
Probably accessing FS anyways is not a bad idea (I'm guessing
that that is what File does as well).
>
> What FS do you use?
the link problem is just on a regular local filesystem (but in general
I'm using primarity local, ftp, and sftp).
Cheers!
- Filip
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [VFS] handling of broken links
Posted by Mario Ivankovits <ma...@ops.co.at>.
Hi!
> Anybody any ideas of how to resolve this ? I'm guessing that
> it should either be a FileType.LINK or a regular FileType.FILE
> and that exists() should return true, but that when accessing
> the content an exception needs to be thrown.
>
Sometimes I think VFS still do a little bit too much on its own logic.
What if we keep the current behaviour but access the filesystem layer
even if the file is not existent? (From VFSs point of view).
Hmmm ... or your FileType.LINK ... I am not sure.
What FS do you use?
Ciao,
Mario
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
[VFS] handling of broken links
Posted by fi...@cirquedigital.com.
Hi,
I noticed something interesting in how VFS is handling symbolic
links that point to a non-existing file. They're mapped to
FileType.IMAGINARY and FileObject.exists() returns false.
You can make arguments that this is not that bad of a choice,
but it seems to be impossible to delete such a broken link
inside of VFS..
Anybody any ideas of how to resolve this ? I'm guessing that
it should either be a FileType.LINK or a regular FileType.FILE
and that exists() should return true, but that when accessing
the content an exception needs to be thrown.
Thanks in advance!
- Filip
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [VFS] Contributions to the project
Posted by Mario Ivankovits <ma...@ops.co.at>.
Hi!
> Oh, and one idea you might want to add to the list, a special
> classloader that would dynamically transform all usage of java.io.File
> to use VFS instead, so that any application could be VFS-enabled. ( I
> might implement that if i have time )
Out of VFS I have seen someone else implemented such a thing by simply
extending from java.io.File and overloading EVERY method with its own
method.
I havent looked at it lately, but it might be possible to create a
"simple" FileWrapper.
---
Mario
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [VFS] Contributions to the project
Posted by Yannick Menager <ym...@yahoo.co.uk>.
Mario Ivankovits wrote:
> For the next version of VFS I'll rework the cache. What I will do is
> to remove the cache at all and allow to decorate a FileObject with a
> e.g. CachedFileObject (or so), then for sure we will have methods as
> you described, though, it should be possible to use VFS without having
> to deal with a cache at all. This might lead to performance loss, but
> the user can decide what he/she would like to have:
>
> *) Refresh cache on demand (as is)
> *) Refresh cache after resolveFile()
> *) Refresh cache before any file operation
Sounds good.
>> 2) VFS Browser
>>
>> An windows explorer type panel to browse a VFS
> There is alread jcommander. They started to adapt it to use VFS.
> Though having a method to extend the default swing "open file" dialog
> would be nice.
I'll have a look, depends on how tighly integrated with the 'filesystem'
concept. My idea for the browser is for it to be completely abstracted
out of it ( so all it's 'actions' would come from the Action/Service
framework ), and the 'Views' would be provided by plugins.
>> 3) File Actions
> There is already a conribution which achieves this. Attached to
> http://issues.apache.org/bugzilla/show_bug.cgi?id=36047 (includes SVN
> access) it waits to have VFS release 1.0 out.
> Such an interface will be used to e.g. commit/update a file, retrieve
> a thumbnail or exif data (in case of an image format wich allows it)
Yes that looks like that might do the job. However one of my
requirements is for the service framework to be able to be used
exclusively with the API, without requiring code to handle it's
different type of services... So basically i want the browser to be able
to display the different actions that can be done on a file when you
right-click on the file, and allow to execute that action, dynamically
building an 'parameter' panel ( unless off course there is a plugin to
especially support the Action/Service.
Also, another concept i needed was Action/Service that are done from one
file to the other ( for drag & drop support )
> Said that, if you would like to jump into VFS development there is
> still enough room, please have a look at:
> http://wiki.apache.org/jakarta-commons/VfsNext
The areas that i'm going to be mostly interested will indeed be the
Service API, aspects.
Oh, and one idea you might want to add to the list, a special
classloader that would dynamically transform all usage of java.io.File
to use VFS instead, so that any application could be VFS-enabled. ( I
might implement that if i have time )
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [VFS] File Type
Posted by Yannick Menager <ym...@yahoo.co.uk>.
I do think the type makes some sense, however in system API, i always
felt it is preferable to use more technical terms, from which the
meaning can be more completely understood just from the name. And of all
the potential terms i can think of, I just feel that Imaginary is one of
the least appropriate ones. Just my personal opinion...
On Fri, 09 Dec 2005 14:32:35 +0100, "Mario Ivankovits" <ma...@ops.co.at>
said:
> Hi Yannick!
> > the FileType.IMAGINARY
> > - A FOLDER, that has childrens, but no data
> > - A FILE, that has no childrens, but has data.
> >
> I dont understand whats that bad with "imaginary" - a file/foler that is
> non existent. Once we cross the bridge where we have to deal with files
> that might have children or folders with content we can introduce new
> FileTypes.
> Or - do not reflect this using file types at all, but introduce
> Capabilities on fileObject level too.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [VFS] File Type
Posted by Mario Ivankovits <ma...@ops.co.at>.
Hi Yannick!
> the FileType.IMAGINARY
> - A FOLDER, that has childrens, but no data
> - A FILE, that has no childrens, but has data.
>
I dont understand whats that bad with "imaginary" - a file/foler that is
non existent. Once we cross the bridge where we have to deal with files
that might have children or folders with content we can introduce new
FileTypes.
Or - do not reflect this using file types at all, but introduce
Capabilities on fileObject level too.
---
Mario
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [VFS] File Type
Posted by Yannick Menager <ym...@yahoo.co.uk>.
There is one thing i was wondering if there was any possibility of
changing in the VFS API.
the FileType.IMAGINARY
Now, let's see.. we have:
- A FOLDER, that has childrens, but no data
- A FILE, that has no childrens, but has data.
The other alternatives would be something that has no childrens or data,
which i can't think of any valid usecase for it, or the much more likely
of a file that has *both* childrens and data (tons of usecases for that
one)
Why not instead use something like FileType.HYBRID, FileType.BOTH,
FileType.VIRTUAL, FileType.OTHER
Anything but 'Imaginary'
I know it's a bit late in the day, but i really think it would be worth
changing that for the 1.0 release.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [VFS] Contributions to the project
Posted by Yannick Menager <ym...@yahoo.co.uk>.
On Fri, 09 Dec 2005 11:12:44 +0000, "Yannick Menager"
<ym...@yahoo.co.uk> said:
> On Thu, 08 Dec 2005 19:54:13 +0100, "Mario Ivankovits" <ma...@ops.co.at>
> said:
> > > 3) File Actions
> > >
> > There is already a conribution which achieves this. Attached to
> > http://issues.apache.org/bugzilla/show_bug.cgi?id=36047 (includes SVN
> > access) it waits to have VFS release 1.0 out.
> > Such an interface will be used to e.g. commit/update a file, retrieve a
> > thumbnail or exif data (in case of an image format wich allows it)
>
> I've had a look at it, but i didn't like the fact that retrieving the
> services is tied up to the java Class (i.e.: FileService
> getService(Class serviceClass) ).
>
> The reason i don't like that approach, is that one of the things i'm
> planning to do, is a 'remote VFS' provider. That provider would not only
> send the information about the files, but also provide the list of
> actions that can be executed on each file, and allow the client VFS to
> remotely invoke those actions. In order to do that with that API, it
> would require the actually classes for all services to be in the
> client's classpath, which is a very bad approach. My idea is to have the
> base API to provide enough information to cover most basic use cases,
> and off course specific implementations of the service can provide
> richer API that the user of the API can make use.
Ok, i've put in an initial draft on my svn server at
http://svn.jguild.com/vfs-contrib/src/org/apache/commons/vfs/action/
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [VFS] File metadata
Posted by Yannick Menager <ya...@yannickm.com>.
Mario Ivankovits wrote:
> Hi!
>> One thought.... shouldn't the file metadata information (i.e.
>> FileContent.getAttributes() ), also be constrained ?
>>
> These attributes are mainly to get attributes stored e.g. in the jar
> manifest. We cant constrain them as we dont know which might exists
>> We could then also use that API to expose and allow to view/modify
>> things like security information (owner, group, permission), svn log
>> history, etc.
>>
> As I said, I think the separate service/... framework would be the
> best way.
So you mean use the Service API both to provide extra information in
addition to Operations/Actions ?
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [VFS] File metadata
Posted by Yannick Menager <ya...@yannickm.com>.
Mario Ivankovits wrote:
> Hi!
>> One thought.... shouldn't the file metadata information (i.e.
>> FileContent.getAttributes() ), also be constrained ?
>>
> These attributes are mainly to get attributes stored e.g. in the jar
> manifest. We cant constrain them as we dont know which might exists
Oh ! I thought they were for metadata attributes, like for example the
SVN attributes... I think it might be better to clarify that in the
javadocs :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [VFS] File metadata
Posted by Mario Ivankovits <ma...@ops.co.at>.
Hi!
> One thought.... shouldn't the file metadata information (i.e.
> FileContent.getAttributes() ), also be constrained ?
>
These attributes are mainly to get attributes stored e.g. in the jar
manifest. We cant constrain them as we dont know which might exists
> We could then also use that API to expose and allow to view/modify
> things like security information (owner, group, permission), svn log
> history, etc.
>
As I said, I think the separate service/... framework would be the best way.
---
Mario
[VFS] File metadata
Posted by Yannick Menager <ym...@yahoo.co.uk>.
One thought.... shouldn't the file metadata information (i.e.
FileContent.getAttributes() ), also be constrained ?
We could then also use that API to expose and allow to view/modify
things like security information (owner, group, permission), svn log
history, etc.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [VFS] Contributions to the project
Posted by Yannick Menager <ym...@yahoo.co.uk>.
Ok, i've updated my draft code at
https://svn.jguild.com/vfs-contrib/src/org/apache/commons/vfs/action
So for example:
FileObject file;
ActionManager actionManager = ...
Action[] actions = actionManager.getActions(file);
SvnCheckout checkoutAction = (SvnCheckout) actionManager.getAction(file,
Class SvnCheckout.class );
-- With SvnCheckout classes available:
checkoutAction.setRevision(55);
checkoutAction.execute();
-- Or without
ActionMetadata actionMetadata = new ActionMetadata( action )
Argument revisionArg = ... gets the right argument out of actionMetadata
...
revisionArg.setValue( new Integer(55) );
action.execute();
On Fri, 09 Dec 2005 15:23:16 +0000, "Yannick Menager"
<ym...@yahoo.co.uk> said:
> Been thinking about this, and you're absolutely right... My preference
> also has always been for the constrained approach, but my mind was a bit
> stuck on my 'remote vfs' usecase *sheepish grin*
>
> Actually nevermind what i said about having an optional loose API, but i
> think i have a much better idea:
>
> Require services to provide the meta-data information that could then be
> transfered and exposed to the client. Using either anotations on 1.5, or
> for example an xml file on older systems.
>
> i.e.:
>
> class SvnCheckout {
> /**
> * @@vfs.service-argument description='bla bla' optional='true'
> */
> public void setPort( int port ) {
> ...
> }
> }
>
> and of course provide API to easily access that information
> independently of it using 1.5 or a fallback method.
>
> On Fri, 09 Dec 2005 14:41:00 +0100, "Mario Ivankovits" <ma...@ops.co.at>
> said:
> > Hi Yannick,
> > >>> 3) File Actions
> > >>>
> > > and allow the client VFS to
> > > remotely invoke those actions. In order to do that with that API, it
> > > would require the actually classes for all services to be in the
> > > client's classpath, which is a very bad approach.
> > I am definitely against having generic interfaces. If I write programs I
> > would like to compile my stuff and can be sure to have no syntax error
> > in it.
> >
> > Having interfaces like
> > setAttribute(String key, String value)
> > is against my wishes.
> >
> > If the value provided is syntactical correct (e.g. setAttribute("port",
> > "abd")) cant be checked during compile time, while
> > SvnCheckout.setPort(123) can be checked.
> > I am sure we find ways to call those services remotely without having
> > all the classes on the client. e.g by providing a RemoteService object
> > which uses reflection on the server side to configure the services then.
> >
> > The same idea I implemented in the *FileSystemConfigBuilder stuff. If
> > you e.g. have to process settings from an xml-file you can use the
> > DelegatingFileSystemObjectBuilder which uses (for sure rather
> > sophisticated) reflection to call the type safe implementations the.
> >
> > ---
> > Mario
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [VFS] Contributions to the project
Posted by Yannick Menager <ym...@yahoo.co.uk>.
Mario Ivankovits wrote:
> Hi!
>> Require services to provide the meta-data information that could then be
>> transfered and exposed to the client. Using either anotations on 1.5, or
>> for example an xml file on older systems.
>>
> Hmmm, what if we use a simple properties file to describe them.
> e.g. SvnCheckout.properties
> port=The port used for communication
> host=The host
> then we can localize them too. We can have separate files or one per
> "service group".
>
> How to mark a parameter optional (or not) is a good point.
Yup, because of that, and other kind of information that will be needed
( i.e. a description of what the action does ), i think an xml would be
a better match
i.e.
<action-metadata>
<description>This action allows to checkout the file on the SVN to the local filesystem</description>
<argument name='revision' optional='true' description='The revision that should be checked out'/>
<argument name='targetDir' optional='false' description='The directory to which the code should be checked out'/>
</action-metadata>
> Today I would use annotations for it (e.g. @NotNull) but we have to
> stick with jdk 1.3 for a while.
> For now we can put then into another properties file too and provide
> the suggested api to query it, so we can change this to annotations it
> we are able to upgrade.
No reason why not have both :-)
If the code is running in a 1.5 vm, check for annotations, if it's not,
or no annotations were found, check for a metadata xml.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [VFS] Contributions to the project
Posted by Mario Ivankovits <ma...@ops.co.at>.
Hi!
> Require services to provide the meta-data information that could then be
> transfered and exposed to the client. Using either anotations on 1.5, or
> for example an xml file on older systems.
>
Hmmm, what if we use a simple properties file to describe them.
e.g. SvnCheckout.properties
port=The port used for communication
host=The host
then we can localize them too. We can have separate files or one per
"service group".
How to mark a parameter optional (or not) is a good point.
Today I would use annotations for it (e.g. @NotNull) but we have to
stick with jdk 1.3 for a while.
For now we can put then into another properties file too and provide the
suggested api to query it, so we can change this to annotations it we
are able to upgrade.
---
Mario
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [VFS] Contributions to the project
Posted by Yannick Menager <ym...@yahoo.co.uk>.
Been thinking about this, and you're absolutely right... My preference
also has always been for the constrained approach, but my mind was a bit
stuck on my 'remote vfs' usecase *sheepish grin*
Actually nevermind what i said about having an optional loose API, but i
think i have a much better idea:
Require services to provide the meta-data information that could then be
transfered and exposed to the client. Using either anotations on 1.5, or
for example an xml file on older systems.
i.e.:
class SvnCheckout {
/**
* @@vfs.service-argument description='bla bla' optional='true'
*/
public void setPort( int port ) {
...
}
}
and of course provide API to easily access that information
independently of it using 1.5 or a fallback method.
On Fri, 09 Dec 2005 14:41:00 +0100, "Mario Ivankovits" <ma...@ops.co.at>
said:
> Hi Yannick,
> >>> 3) File Actions
> >>>
> > and allow the client VFS to
> > remotely invoke those actions. In order to do that with that API, it
> > would require the actually classes for all services to be in the
> > client's classpath, which is a very bad approach.
> I am definitely against having generic interfaces. If I write programs I
> would like to compile my stuff and can be sure to have no syntax error
> in it.
>
> Having interfaces like
> setAttribute(String key, String value)
> is against my wishes.
>
> If the value provided is syntactical correct (e.g. setAttribute("port",
> "abd")) cant be checked during compile time, while
> SvnCheckout.setPort(123) can be checked.
> I am sure we find ways to call those services remotely without having
> all the classes on the client. e.g by providing a RemoteService object
> which uses reflection on the server side to configure the services then.
>
> The same idea I implemented in the *FileSystemConfigBuilder stuff. If
> you e.g. have to process settings from an xml-file you can use the
> DelegatingFileSystemObjectBuilder which uses (for sure rather
> sophisticated) reflection to call the type safe implementations the.
>
> ---
> Mario
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [VFS] Contributions to the project
Posted by Yannick Menager <ym...@yahoo.co.uk>.
My idea was not that it should be exclusively based on the 'loose'
model, but rather that the loose model would be provided by all
interfaces, in addition to the constrained one.
So SvnCheckout could have it's port set by using setAttribute("port",
"123") (which would be provided by the top interface), or by using
setPort(123) (which would be provided by the SvnCheckout interface).
Rather sofisticated reflection or bytecode engineering is a problem the
moment it requires permission that might not be allowed in certain
situations (Applets).
HHmmm... but now that i think about it, we can have 2 interfaces, one
which is the parent one for all actions/services, and another one for
services that expose a 'loose' interface... What do you think ?
On Fri, 09 Dec 2005 14:41:00 +0100, "Mario Ivankovits" <ma...@ops.co.at>
said:
> I am definitely against having generic interfaces. If I write programs I
> would like to compile my stuff and can be sure to have no syntax error
> in it.
>
> Having interfaces like
> setAttribute(String key, String value)
> is against my wishes.
>
> If the value provided is syntactical correct (e.g. setAttribute("port",
> "abd")) cant be checked during compile time, while
> SvnCheckout.setPort(123) can be checked.
> I am sure we find ways to call those services remotely without having
> all the classes on the client. e.g by providing a RemoteService object
> which uses reflection on the server side to configure the services then.
>
> The same idea I implemented in the *FileSystemConfigBuilder stuff. If
> you e.g. have to process settings from an xml-file you can use the
> DelegatingFileSystemObjectBuilder which uses (for sure rather
> sophisticated) reflection to call the type safe implementations the.
>
> ---
> Mario
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [VFS] Contributions to the project
Posted by Mario Ivankovits <ma...@ops.co.at>.
Hi Yannick,
>>> 3) File Actions
>>>
> and allow the client VFS to
> remotely invoke those actions. In order to do that with that API, it
> would require the actually classes for all services to be in the
> client's classpath, which is a very bad approach.
I am definitely against having generic interfaces. If I write programs I
would like to compile my stuff and can be sure to have no syntax error
in it.
Having interfaces like
setAttribute(String key, String value)
is against my wishes.
If the value provided is syntactical correct (e.g. setAttribute("port",
"abd")) cant be checked during compile time, while
SvnCheckout.setPort(123) can be checked.
I am sure we find ways to call those services remotely without having
all the classes on the client. e.g by providing a RemoteService object
which uses reflection on the server side to configure the services then.
The same idea I implemented in the *FileSystemConfigBuilder stuff. If
you e.g. have to process settings from an xml-file you can use the
DelegatingFileSystemObjectBuilder which uses (for sure rather
sophisticated) reflection to call the type safe implementations the.
---
Mario
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [VFS] Contributions to the project
Posted by Yannick Menager <ym...@yahoo.co.uk>.
On Thu, 08 Dec 2005 19:54:13 +0100, "Mario Ivankovits" <ma...@ops.co.at>
said:
> > 3) File Actions
> >
> There is already a conribution which achieves this. Attached to
> http://issues.apache.org/bugzilla/show_bug.cgi?id=36047 (includes SVN
> access) it waits to have VFS release 1.0 out.
> Such an interface will be used to e.g. commit/update a file, retrieve a
> thumbnail or exif data (in case of an image format wich allows it)
I've had a look at it, but i didn't like the fact that retrieving the
services is tied up to the java Class (i.e.: FileService
getService(Class serviceClass) ).
The reason i don't like that approach, is that one of the things i'm
planning to do, is a 'remote VFS' provider. That provider would not only
send the information about the files, but also provide the list of
actions that can be executed on each file, and allow the client VFS to
remotely invoke those actions. In order to do that with that API, it
would require the actually classes for all services to be in the
client's classpath, which is a very bad approach. My idea is to have the
base API to provide enough information to cover most basic use cases,
and off course specific implementations of the service can provide
richer API that the user of the API can make use.
Yours truly
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [VFS] Contributions to the project
Posted by Yannick Menager <ym...@yahoo.co.uk>.
Mario Ivankovits wrote:
> Say you have an application where you simply could "open" or "save as"
> files, e.g. picture viewer/converter, jedit or so on.
> Then it might be nice if we have a swing/awt component which utilize VFS.
> I guess it should be possible to extend the common "open file" dialog,
> isnt it?
Not impossible, but *very* hard to do.
The way to do that is to replace all calls to filesystem IO with call to
VFS.
Unfortunately, the java.io.FileSystem is protected, so even using
priviledged reflection, that can't be done.
The only way i can think of is some fancy bytecode
generation/replacement. Either of the FileSystem of a running
application ( but i strongly suspect that's impossible, or extremely
hard at minimum), or alternatively to change the bytecode of the
application.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [VFS] Contributions to the project
Posted by Robert Enyedi <re...@gmail.com>.
Hi Mario,
Say you have an application where you simply could "open" or "save as"
> files, e.g. picture viewer/converter, jedit or so on.
> Then it might be nice if we have a swing/awt component which utilize VFS.
> I guess it should be possible to extend the common "open file" dialog,
> isnt it?
Unfortunately there is no way to change the Swing file chooser dialog so
that it would browse the file systems with VFS. In fact that component
contains so many hacks and partially implemented features (shortcuts to My
Computer, Network Neighbourhood, Desktop and retrieval of operating system
file icons) that I don't think anyone would want to work on it (except major
refactoring) even if it would be open source.
Both AWT and SWT use the operating system's file chooser so that can't be
changed either to use VFS.
So we're left with implementing it from scratch. And now that you mentioned
it I think that at some point we might need this feature in JCommander (this
will be a SWT/JFace implementation and not Swing). Certainly this will be
required when we will provide an internal file editor (based on the powerful
Eclipse editor framework). In fact I have created the " File dialog based on
VFS<http://sourceforge.net/tracker/index.php?func=detail&aid=1376567&group_id=35271&atid=413698>"
feature request (with Research status) for JCommander here:
http://sourceforge.net/tracker/index.php?func=detail&aid=1376567&group_id=35271&atid=413698we
warmly welcome you all there for a brainstorming session :-)
Regards,
Robert
Re: [VFS] Contributions to the project
Posted by Mario Ivankovits <ma...@ops.co.at>.
Hi Robert!
> Mario, what do you mean by extending the swing "open file" dialog?
>
Say you have an application where you simply could "open" or "save as"
files, e.g. picture viewer/converter, jedit or so on.
Then it might be nice if we have a swing/awt component which utilize VFS.
I guess it should be possible to extend the common "open file" dialog,
isnt it?
---
Mario
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [VFS] Contributions to the project
Posted by Robert Enyedi <re...@gmail.com>.
Hi,
> 2) VFS Browser
> >
> > An windows explorer type panel to browse a VFS
> >
> There is alread jcommander. They started to adapt it to use VFS. Though
> having a method to extend the default swing "open file" dialog would be
> nice.
>
Yes, the upcoming JCommander 0.7.0 (http://jcommander.sf.net) version will
make full use of the VFS features. I will post here when it will be
available so you guys can take a look at the approach and maybe help us out
by providing feedback.
Mario, what do you mean by extending the swing "open file" dialog?
Regards,
Robert
Re: [VFS] Contributions to the project
Posted by Mario Ivankovits <ma...@ops.co.at>.
Hi Yannick,
> Recently i've decide to dedicate some time on it, and since VFS seems to
> fullfill some of my requirements, i was thinking of extending it,
thanks for your interest in VFS.
> 1) Cache API.
>
For the next version of VFS I'll rework the cache. What I will do is to
remove the cache at all and allow to decorate a FileObject with a e.g.
CachedFileObject (or so), then for sure we will have methods as you
described, though, it should be possible to use VFS without having to
deal with a cache at all. This might lead to performance loss, but the
user can decide what he/she would like to have:
*) Refresh cache on demand (as is)
*) Refresh cache after resolveFile()
*) Refresh cache before any file operation
> 2) VFS Browser
>
> An windows explorer type panel to browse a VFS
>
There is alread jcommander. They started to adapt it to use VFS. Though
having a method to extend the default swing "open file" dialog would be
nice.
> 3) File Actions
>
There is already a conribution which achieves this. Attached to
http://issues.apache.org/bugzilla/show_bug.cgi?id=36047 (includes SVN
access) it waits to have VFS release 1.0 out.
Such an interface will be used to e.g. commit/update a file, retrieve a
thumbnail or exif data (in case of an image format wich allows it)
Said that, if you would like to jump into VFS development there is still
enough room, please have a look at:
http://wiki.apache.org/jakarta-commons/VfsNext
Thanks,
Mario
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org