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: neutral (asf.osuosl.org: local policy)
Message-Id: <1134141796.16904.249422740@webmail.messagingengine.com>
From: "Yannick Menager" <ymenager@yahoo.co.uk>
To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="ISO-8859-1"
MIME-Version: 1.0
References: <1134065792.30690.249349960@webmail.messagingengine.com>
   <43988155.8070306@ops.co.at>
   <1134126764.24224.249407753@webmail.messagingengine.com>
   <4399896C.6000708@ops.co.at>
Subject: Re: [VFS] Contributions to the project
In-Reply-To: <4399896C.6000708@ops.co.at>
Date: Fri, 09 Dec 2005 15:23:16 +0000

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" <mario@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