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]
