commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Yannick Menager" <>
Subject Re: [VFS] Contributions to the project
Date Fri, 09 Dec 2005 15:23:16 GMT
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.


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" <>
> 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:
> For additional commands, e-mail:

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

View raw message