A sign of great design is that problems you never thought of are solved for free. So let's look at the upgrading problem which I considered long ago insoluble and certainly uninteresting.
Today I was thinking about 'embed vs extent'. And I observed that despite embed being clearly Evil, it offered some (bad) solution to the upgrading problem. The problem of all your apps getting fucked over by the latest "upgrade".
Now, thinking some more about it I decided the solution was to allow upgrading of shared code and then revert locally whenever something broke. So if you have a movie and it breaks when the movie playing software upgrades then that particular movie should use the older code. Which should still be available.
And then I wondered at the costs of implementing this solution. But in my design I already have universal versioning of absolutely everything. And I already even have versioned object-capabilities that can point to the #latest or #53 of some software.
So all it takes to "implement" this scenario is to point a type of object as using version #53 of the software instead of #latest. Which is something the *user*, not the admin or the programmer, can do.
In other words, the cost is free. I don't have to do ANYTHING except teach the users what to do when some software upgrade breaks other code. Which is not to revert the entire update, which they can also do, but to revert it LOCALLY. Something they wouldn't realize they can do.
And the only limitation of the solution is if software takes it upon itself to be Evilly intransigent. If it presumptuously arrogates for itself the authority of deciding what version of some sub-software it's going to use instead of asking the user to provide one.
Which typically happens when modular software tries to pretend it's monolithic. As in Applications. This is bad code and is yet another reason to despise applications.
So the solution works so long as you're not dealing with malicious code. For free. That's pretty good.
No comments:
Post a Comment