On May 25, 2010, at 1041AM, Gregg Wonderly wrote: > Peter Firmstone wrote: >> Dennis Reedy wrote: >>> - Given the capability above, the need for a codebase service may not be >>> required >>> >> Agreed > > One of the things that we need to consider, I believe, is the ability for a > client/UI to run without any service/network visability. Imagine devices > using a services UI in a disconnected environment and later connecting for > interaction with the service. The codebase server, today requires caching > downloading and many interesting twists to how the content of the clients > "classpath" is managed for disconnected operation. Using a more detached > update mechanism more like we see in more modern network environments can > really help. It does, however, present more of an opportunity for codebase > rot to occur which can cause a client to run without the right software in > place when it attempts to connect to a service. > > The existing codebase mechanism has the benefit that you automatically, > always get exactly the software that the service needs you to use on the > client end. > > We should think about how to deal with the chasm that exists between these > two mechanisms. > > It is true that there are some service evolution practices that make this > less likely. > > If there are things that we can document or compartmentalize to make it > easier to use a deferred update mechanism that would be great. > > I worry about what might happen if a client is started off the network, and > then brought into a network environment where it can make contact with the > service without having updated the code because of how the order of events > transpired.
These are all good issues. I think more rigor needs to be put into how service artifacts are updated, and what attributes we look for when we seek to discover services. Using version numbers in both the produced artifacts and ensuring that services advertise version numbers (as part of net.jini.lookup.entry.ServiceInfo), and that we look for specific version numbers for a service we want to use can help with this issue. Perhaps (and I'm not sure this has been discussed before) having a range of versions that a service provides support for could also help address this issue. If the client determines it is out of synch, the deferred update approach certainly allows the client to choose to use remote class loading or provision that requisite jars.
