Pref Migration Summary
Luke Schierer
lschiere at pidgin.im
Wed Apr 11 14:32:54 EDT 2007
On Wed, Apr 11, 2007 at 02:21:07PM -0400, Warren Togami wrote:
> (Just summarizing what was discussed in #pidgin today.)
>
> .gaimrc (ancient version)
> .gaim (1.5.x)
> .pidgin (2.0.0+)
>
> Shared Homedir Case
> ===================
> This is a relatively rare case, but problematic for those users if
> gaim-1.5.x and pidgin-2.0.0+ insists on keeping a shared prefs
> directory. Problems include:
> - 1.5.x confused by prefs written by 2.0.0+. Behavior is odd and
> sometimes broken.
> - Prefs written by 1.5.x break some prefs written by 2.0.0+, requiring
> you to reconfigure when you run 2.0.0 again. This is the flip-flopping
> problem.
> - 2.0.0 might be able to be modified in an attempt to avoid
> flip-flopping with 1.5.x's pref handling. However, if this remains a
> requirement, then pidgin is probably hindered in future progress.
>
> It is broken and unsustainable to attempt to share preferences between
> 1.5.x and 2.0.0 and avoid changes that would break the former. The
> prefs between these versions should be made independent. Doing so, we
> avoid problems for users with strange/broken client behavior and
> flip-flopping of preferences.
>
> Use .gaim Forever?
> ==================
> Luke (and others) indicated that if we don't make a change away from
> .gaim now, we will be stuck with it for a while.
>
> pidgin-2.0.0 one-time migration
> ===============================
> If .gaim exists DO NOT MODIFY IT. Instead migrate it to .pidgin. .gaim
> is left untouched, so if 1.5.x runs, it isn't confused by prefs written
> by newer versions. Furthermore, prefs are not flip-flopping if you
> again run 2.0.0 after 1.5.x.
>
> A one-time migration would be a SIMPLE and working solution that avoids
> limitations for future development.
Just a minor note, that we would probably use .purple and not .pidgin.
Finch would use this directory also.
>
> Shared Logging Handling: OPTIONAL?
> ==================================
> It was discussed that Pidgin could intelligently handle logs in either
> location. Somehow. Implementation details were vague.
>
> IMHO, this really isn't important to do at all. It is simpler and the
> right thing to just keep the logs separate after the one-time migration.
>
> Why? The shared user homedir case is rare. Those users are more
> concerned with the client working (avoid pref flip-flopping) than logs
> being consistent.
>
> Furthermore, if you try to maintain shared logs, then this creates
> complications if the log format wants to change again in the future.
>
> Now, if somebody can think of a sane way to implement this, keeping in
> mind that 1.5.x's log handling behavior wont change, then go ahead. I'm
> doubtful that this important at all.
RLaager is concerned with this issue. He suggested that we could teach
the 2.0.0 viewer to continue to look in .gaim, but forget about the
ability of 1.x to see 2.0.0 logs. This is a forward portable solution,
and unlike actually writting to .gaim, I think it is one that we would
be able to rethink in a year or two without having to revisit the same
exact arguments.
>
> Symlink Case
> ============
> Stu was concerned about the extreme minor of power users or devs that
> have symlinks within their gaim/pidgin prefs. Given that this is not a
> default
>
> The code could detect symlinks and handle it appropriately. What is the
> appropriate way to handle it? This isn't clear.
>
> Given how rare and non-standard this is, it is probably best to keep the
> code simple and ignore it. Users who did this to themselves are smart
> enough to fix it on their own.
Worrying about users with either a symlinked .gaim or, worse, symlinks
inside .gaim, seems, to me, to force us to use .gaim, if it exists now,
endlessly. Any arguement that would prevent us from migrating now
because of such users would apply equally well a month from now, a year
from now, and so on.
I suspect the mentality here is that those who have used gaim now will
always remember and realize that Pidgin & Finch were at one point Gaim,
in the event that they have to look for this directory manually. While
such situations should naturally be avoided, they do happen. Examples
right now include wanting to use unix text utilities in place of our log
viewer, wanting to remove logs on any system, and finding the xml files
to submit bug reports.
I strongly suspect that as time passes, people will move on in their
lives and forget that Pidgin & Finch were once called Gaim. They will
no longer expect that they would be using .gaim, and may even shoot
themselves in the foot by deleting an "old" dotfile. For these reasons,
I very much want to see us leave .gaim behind us, naturally with code to
import its information in some way, but in a way that after that import
users need no longer care about it.
I would go so far in this as to say that logs either should be coppied
over automatically, or that we should at very least offer to do so for
the user. Again, I suspect that as time passes, people will cease to
expect that .gaim has anything they would want or need.
luke
More information about the Devel
mailing list