Sim IJskes - QCG wrote:
Peter Firmstone wrote:
The bad news is that ClassLoader's are memory hungry, so we'll soon
run out of both network bandwidth and memory when downloading
multiple duplicate codebases all providing similar services.
How would an internet deployment work in practice?
Services, provided from multiple locations / domains worldwide,
discovered by clients using DNS-SD. I can set up an example from my domain.
When you use a
service you need to know its interface. So how many interfaces are we
going to standardize? And those services are they similar, or the same?
We can standardize some, but we don't really need to standardize, we can
create a place where people can submit their interfaces for others to
use and this can become an organic thing based on usefulness or popularity.
It is absolutely essential to ensure that interfaces reside in a
ClassLoader separate to any implementation, due to ClassLoader
visibility constraints.
The only benefit to service proxies would be to distribute an updated
version, or when its a big one that you only keep it in memory when
you use it (and i'm not sure classloaders easily give up codebases).
Have a look at codebase services by Michael Warres. I have a copy of
his paper if your interested.
Code needs to be deployed anyhow. Once at installtime, or when there
are updates, or with every invocation of the program. We have
'downloads', java webstart, jini. With every step we gain extra
agility(?). What real scenario, use-case are we facilitating here?
Peer to peer, internet distributed group collaboration applications
would be a good start.
Shouldn't we make a few usecases and maybe create a few personas, so
we all get a feel for what problem we are solving here?
Ok I'm open to it.
Gr. Sim
Cheers,
Peter.
