Re: [Alephmodular-devel] Plist preferences (was: Developer Rant #1 :) )

[Woody Z. I. <woo...@sb...>]

I should make explicit that my comments about the usefulness of plist 
preferences were made before I received this message from Br'fin.  Those 
comments would have been different otherwise.  Though I don't recall 
exactly where I came down in that A1 discussion, what Br'fin's saying 
here makes sense to me.

Right, maintaining backwards-compatibility (even with earlier versions 
of itself) has been another particularly weak spot in A1.  Now *there* 
might be a good argument for AM's "back to basics" approach.

OK, I _swear_ I'm shutting up now ("and there was much rejoicing"), 
because I have to test and submit a few more patches for A1.  And assign 
percussion parts for Shostakovich's 1st symphony.  :)

So umm, everybody please quit saying interesting things.  ;)  (Ha ha, I 
am only kidding of course.)

Woody


On Tuesday, January 14, 2003, at 08:30  PM, Br'fin wrote:

> A correction to the issue of plists.
>
> Folks were looking to redo the preferences in XML. My suggestion of XML 
> specification was for plists. (I wasn't even suggesting using the OSX 
> APIs to access these files!) This would have been a cross-platform and 
> XML-based preferences file with the additional bonus that under OSX 
> there were tools to read/write plists *outside* of A1.
>
> As an additional bonus, plists aren't tied to the needs of any one 
> program. So if one platform needed an extra preferences item, it could 
> add it without requiring additional XML tags and code in A1.
>
> ....
>
> How fascinating.
>
> You know where the MML vs PLIST XML preferences came up? April 2002.
> What did it arise from? The accursed preferences related assert bug
> What was done? Loren redid the preferences in a custom XML format.
> When were we still finding the accursed assert? October, 2002
>
> Now I'm pretty sure the preferences were changed to XML and released 
> (With fun havok there since that also was a sudden change and I don't 
> remember any preferences converting code as being part of the deal...) 
> So this must have been old AlephOne versions floating around without us 
> thinking about it.