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" <[EMAIL PROTECTED]>
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: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
