At 12:06 PM 10/12/2005 -0700, Bryan Stearns wrote:
I've got some concerns about this proposal: the ability to upgrade seems
centered around being able to upgrade running Python code on-the-fly,
Code reloading is an internal development feature that has been requested
by John and Donn. In implementation terms, it's entirely unrelated to the
rest of the issues. As you may recall, I listed four different issues I
would talk about; these could be subgrouped into "reloading issues" and
"schema issues", with the former having to do with on-the-fly upgrades, and
the latter being independent (and implicitly assumed to be operations
requiring a restart).
Frankly, the idea of changing the schema with Chandler running (aside from
adding new classes, which already works) never occurred to me as a
requirement or even a possibility.
as well as to upgrade Chandler's schema without quitting Chandler. These
abilities appear to complicate the solution you've chosen,
Not so. I simply commented on the fact that there are a few types of
schema change that work *now* without quitting Chandler. I never stated
this as a requirement, and it never was a requirement. I was simply
enumerating the types of changes that can happen and their current effects
on the system as it exists today.
No part of the schema evolution mechanism I discussed called for any sort
of on-the-fly upgrading. For all practical purposes, you can cut my post
in half and consider the items relating to updating code and UI items,
entirely separately from those involving schema and user data items. If
you do that, it should be clear that I'm in agreement with you: on-the-fly
schema upgrading is not required. I merely mentioned that adding new
classes on-the-fly is in fact possible now, without comment on the
usefulness or desirability of that feature.
Instead, I'd suggest a much simpler strategy is appropriate:
- Build a mechanism for schema upgrades that runs against a closed
repository; it could run as a separate tool, or at Chandler startup time
when Chandler detects an older repository.
The portion of my post that deals with schema evolution and user data
upgrades actually assumes that this will be the approach, so this
suggestion doesn't change anything in my post or reduce the essential
complexity of the problem in any way.
- Take advantage of John's suggestion to have the upgrade mechanism be
cognizant of our ability to discard and reload UI blocks completely; only
worry about upgrading content item schema and instances, and
preference/account settings.
As it happens, I didn't even get into this subject at all, so your
suggestion also doesn't reduce any of the complexity in the issue I did
write about. UI evolution in the presence of user preferences is an
entirely separate problem, caused by the conflation in CPIA between what's
effectively "code" (or template) and what's effectively "data" (or
parameters), placing them in the same item instead of different
items. (The need to have any block copying in the first place, is also a
symptom of this confusion.)
The topic of UI upgrades does indeed fall under my theme of "upgrading",
but my understanding was that we were going to assume that UI location
preferences would be lost under upgrade for the time being, so I chose not
to delve into this at the present time.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
