Re: [Setup-tool-hackers] Fine-grained location management

[Bradford Hovinen <hovinen ximian com>]

On 24 Jan 2001 14:15:12 -0600, Chema Celorio wrote:
> On 24 Jan 2001 12:09:03 -0500, Bradford Hovinen wrote:
> > When a child location partially defines the data for a particular
> > backend, it must store only those configuration settings that the user
> > explicitly changed when updating that backend's configuration under
> > that location. If the frontend simply dumped its entire XML snapshot
> > to the log, all of the configuration settings would be reflected in
> > that snapshot, and under the method indicated above, partial
> > containment would be equivalent to full containment. Therefore, when a
> > frontend stores its configuration under partial containment, the
> 
> Where/who is destion made about using a partial or full containment ?

(I'm assuming you mean "distinction" or "decision" here)

I hadn't thought about that. It could conceivably be an explicit option
sent to the user, but that might be confusing...

In practice, the system will operate just fine even if no derived
locations have full containment, so there might be no reason to make
this distinction.

One thought is just to set the location to full containment if all of
the settings have changed. There should also be a distinction between
settings that just happen to be the same from parent to child and
settings that are actually derived from the parent.

> I am aslo wondering if this will not confuse users.
> 
> For example user has :
> 
> Location home 
> IP : 1.2.3.4
> DNS: 11.22.33.44
> 
> Location office 
> IP : 3.3.3.3
> DNS : 11.22.33.44
> 
> If we do a parial comparison here, we will discover that the difference 
> between locations is in the IP's. If he later changes the DNS while he
> is
> in the office location, wouldnt he be confused that the home location 
> changed DNS too ?

Under the scheme that I indicated above, DNS would only change for the
office location. When he makes that change under the office location,
that setting comes under the containment of that location. The problem
crops up when the user actually wants the setting to change for both
locations. Let me think about that.

> Is the current design of the location management taking into account
> that there are some settings that are not "locatable", I am thinking
> about
> the disks-tool & the users-tool. How does the archiver identify what is
> locatable or not ? 

There's no provision for doing this now, but you have a good point. The
best solution is to have a single base location and make sure that
non-"locatable" settings be covered by that location only. There must
then be a way to tell the GUI that a location cannot contain particular
backends, but that's not too difficult.

I'm thinking about the problem in a wider context. To generalize the
above, we need a way to differentiate between settings that should be
changed in an underlying location and settings that should come under
the control of the derived location. I think Miguel and I tentatively
came up with a solution to this in August: have the settings not under
the control of the current location be grayed out. The user must then
explicitly bring them under the control of the current location.

Under that solution, new users who are not aware of location management
would not have any trouble, since all the settings are covered
automatically by the initial default location. Users that see controls
greyed out are at least exposed to the idea of location management, so
they may understand why they are greyed out. What do you think?

> regards,
> Chema

-Bradford Hovinen

We are most probably here for local information-gathering and
local-Universe problem-solving in support of the integrity of
eternally regenerative Universe.

   -- R. Buckminster Fuller



_______________________________________________
Setup-tool-hackers maillist  -  Setup-tool-hackers@helixcode.com
http://lists.helixcode.com/mailman/listinfo/setup-tool-hackers