Maybe off topic, maybe not... Is there any mileage in setting up a River services repo. Sort of link most Linux distributions have know sites and mirrors where you can browse for applications and receive application updates.
Think of "normal" HTTP/S codebase servers, service interfaces could be published there (somehow) and users can elect to download new versions of services as and when they become available. Obviously, setting and managing the hosting of services would be expensive so we would only host the lookup services. It raises an interesting (I think) question of if our lookup services trust the provider of the service, and the client code trusts our lookup service, can the client code implicitly trust the proxy we refer it to? On Thu, Feb 11, 2010 at 6:12 AM, Sim IJskes - QCG <[email protected]> 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? 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? 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). > > 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? > > 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? > > Gr. Sim > > -- > QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl > Quality Consultancy Group b.v., Leiderdorp, Kvk Leiden: 28088397 >
