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.

Gregg Wonderly

Reply via email to