Phillip J. Eby wrote:
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.)
I either don't understand or don't agree. Trees of blocks are only
parameters (not code, or preferences) -- ignoring the fact that a block
belongs to a class that has methods. The fact that we make a copy of a
template, just means we need a new set of parameters for a new
situation, since we can't know all the situations when the repository is
built.
It's no different from having a bunch of prebuilt Word documents
available, so that when you begin a new document, you make a copy of one
of the templates. Both the templates and the documents you've already
created are data only, not code.
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
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
