My apologies for taking so long to post my objections, but I was  
completely swamped with WWDC07 the last few weeks, and had very little  
time to see my kids, let alone deal with NetBSD stuff.

On Jun 7, 2007, at 7:13 AM, Jachym Holecek wrote:

> Hello,
>
> I'd like to propose a couple of changes to proplib(3), implemented
> by the code at:
>
>  Patch against -current src/ [165KB]:
>    ftp://ftp.NetBSD.org/pub/NetBSD/misc/freza/prop/libprop.diff
>
>  Regression tests to replace regress/lib/libprop:
>    ftp://ftp.NetBSD.org/pub/NetBSD/misc/freza/prop/libprop-regress.tar.gz
>
>  Online-browsable versions:
>    ftp://ftp.NetBSD.org/pub/NetBSD/misc/freza/prop/src.common/
>    ftp://ftp.NetBSD.org/pub/NetBSD/misc/freza/prop/ 
> regress.lib.libprop/
>
> The changes are:
>
>  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.  Yes, I know there is one place  
where it bleeds through in the current code:  
_prop_object_internalizer_table[] in prop_object.c.  However, aside  
from that, it's all contained within the object class implementations  
themselves.

Your changes violate this basic design principle.  You need to fix  
your code accordingly.

>  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
>
>  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.  All you XML haters need to just  
get over it.  There is NO ADVANTAGE to having another plain-text  
serialization format when you consider that the format we already have  
is already in wide use (by Mac OS X / Darwin, not to mention GNUstep  
and some of the other Core Foundation property list work-alikes out  
there), especially when the format chosen has no prior art, and  
therefore no cross-platform compatibility.

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).

But, really, there is apparently nothing other than personal taste  
that is driving stuff like "SCN".  I think there needs to be a very  
high bar set for gratuitous "personal taste" changes like this when  
there are no concrete technical advantages.  I must say that I am  
somewhat disappointed that Core hasn't put a stop to this N-I-H  
nonsense.

-- thorpej