# Jason Thorpe 2007-06-26:
> > o Split encoding-specific bits from the rest of the code.
> >   See common/include/prop/prop_codec.h
> >	common/lib/libprop/prop_codec_impl.h
> >	common/lib/libprop/prop_codec.c
> 
> One of the basic design principles of proplib was that each object  
> type is completely self-contained.

I'm aware of this. The rationale behind exposing object internals
in a (private to the library) header file is that codec implementations
need access to them, and it seems better to keep codec code in separate
files rather them spreading per-codec ifdefs in object implementations.

Also note that (related to the private discussion between the two of
us and dillo@ a couple of days back), at least dictionary/array locks
need to be reachable by non-object-specific parts of proplib.

I agree this could have been done with some internal-API creativity,
but honestly that seemed like bloat. Proplib is a fairly small library
and enforcing the "no object touches other object's internals" policy
(which I agree with, and haven't violated AFAICR) seems easily
archievable by convention (as opposed to technical measures).

> > o Teach the library to support multiple codec backends,
> >   these are selected at compile time.
> >   See common/lib/libprop/prop_codec.c
> >	common/lib/libprop/prop_xml.c
> >	common/lib/libprop/prop_scn.c

From the rest of your replies it seems (but is not entirely clear) you're
not against the general idea of supporting multiple codecs, correct?

Maybe it's better to discuss support for multiple codecs and the new
format as separate topics.

> > o Add a new codec (called "SCN") in addition to XML format.
> >   See common/lib/libprop/prop_scn.c
> >	[example follows below]
> 
> In some ways, I am dumbfounded that we're still discussing the  
> serialization format used by proplib.

Core voted against XML plists in /etc. I think it would be a pity
to lose the option to use proplib for configuration files, so I
went ahead and designed something that would hopefully be considered
sufficiently "user friendly" for the purpose (the key seemed to
be "look a bit C-like" and "keep syntax overhead minimal").

Obvious implication of this is that the format follows my personal
taste.

> All you XML haters need to just get over it.

Don't put feelings into my head -- I don't hate XML, I just don't
passionately love it. In practice, I find hand editing XML less
painful than some of the traditional UNIXy text formats (but more
painful than some others).

> If you want a very compact, fast-to-parse format, then implement the  
> OS X binary property list format (I can provide information about this  
> format upon request; it's actually documented in a header file in the  
> open source Core Foundation sources).

I've done most of the SCN work a couple of weeks back and won't
have to time play around with proplib in major ways for a couple
of weeks. But yes, a fast and compact format would be nice.

I think I'll ask Core for decision about SCN -- clearly I'm too biased
myself and there's no point in turning this discussion into a flamefest
(which seems to be where it's headed).

	-- Jachym