On 6/26/07, Alan Barrett <apb@cequrux.com> wrote:
> On Tue, 26 Jun 2007, Trevor Talbot wrote:

> > >All that's necessary for you to be able to edit in your preferred
> > >format is for *one* proplib-using application to expose the ability to
> > >convert between different formats.  Then you run "plistedit --format
> > >xyzzy /etc/foobar.conf" instead of "vi /etc/foobar.conf".  Yes, this is
> > >jumping through a hoop, but I think it's an easy jump.

> > Right, but once you're at this stage of using a format-converting tool
> > to edit your supposedly human-friendly no-tools-required configuration
> > files, you've completely lost the benefits of having so many formats.

> You seem to be saying:  "If you use a format-converter, ostensibly to
> take advantage of having multiple formats, then you actually lose the
> benefit of having multiple formats."  Sorry, I can't understand the
> reasoning behing such a statement.

I understood the value of 8,000 human formats as presented earlier to
be that the configuration files would always be in the user's
preferred format, and proplib would magically let them work.  The
problem is, configuration files come from various sources, and this
lack of consistency means the user will end up having to do conversion
at various times.  Rather than trying to remember the special cases,
you just end up in the pattern you described above -- using a wrapper
that consistently provides the behavior you want.

Instead of that value being realized as user-tailored simplicity, the
result is complexity that requires the user to do more work just to
get consistency back.  IOW, I'm saying the apparent advantage of
having 8,000 formats in proplib is actually a major disadvantage.

> > Might as well just pick one format and let the editing tool do all the
> > work, since nothing else benefits from it.

> I think you misunderstood me.  There is no specialised "editing tool"
> in my scenario, there's just the user's favourite text editor, being
> invoked on a temporary file in the user's favourite format.  My
> hypothetical "plistedit" application does hardly any work; it's just a
> few proplib calls to convert the input into a temporary file in whatever
> format the user asked for, fork/exec to run the user's preferred editor,
> and then a few proplib calls to convert the file format back again and
> replace the original file.

I did understand that to be what you meant, but from a user
perspective it's no different from a specialized editing tool that
does the same conversion itself, using proplib only to read and write
the One True Format the file was originally in.

A typical proplib user doesn't benefit from 8,000 supported formats
(supposed to obey user preference), the end user doesn't benefit
(using tools anyway as above), only the converter/wrapper does.  So
why should this special presentation/editing issue be part of proplib
itself?  Just make it part of the user's editing tool, even if it's
merely a file-converting wrapper thingamajig.