Re: proplist [was: Importing xmlgrep into base]

[Aleksej Saushev <asau%inbox.ru@localhost>]

Nhat Minh Le <nhat.minh.le%huoc.org@localhost> writes:

> At Sat, 17 Apr 2010 12:39:58 +0400,
> Aleksej Saushev wrote:
>> 
>> Adam Hoka <adam.hoka%gmail.com@localhost> writes:
>> 
>> > On Fri, 16 Apr 2010 13:04:29 +0300
>> > markucz%gmail.com@localhost wrote:
>> >
>> >> Flaming left aside, I think SDL[1] is a good choice - it's easily parsed
>> >> *and* it's human-readable and editable. It seems somewhat akin to what
>> >> named.conf uses though it has some XML-ish constructs. Not as good as 
>> >> s-exps
>> >> (yes, I know it's highly subjective) but still better than XML.
>> >> 
>> >> Regards
>> >> 
>> >> [1]http://www.ikayzo.org/confluence/display/SDL/Home
>> >
>> > Again: WE ALREADY HAVE A NON-BINARY ON-DISK FORMAT FOR PROPLIB.
>> 
>> There's one minor problem with this format: there're almost no tools
>> around to deal with it, and the only tool in NetBSD is patched up.
>> As such, there's close to zero use of this non-binary format.
>
> You can't expect a new format to just take over everything that's been
> in base for the last fifteen years. And IMHO, there need to be tools
> to deal with said format before it can spread.

proplib is in base for last 2 years at least, if it is there to make
life easier, we should see good examples of its use around.
Alright, I see some sign of that in Adam's blog, but I see
counterexample of Matthew's SXML interface. This alone means that the
whole story about proplib is controversial, and plist should not have
been adopted at the first place.

>> That it is already imported is a mistake.
>> 
>> And all this flame is about not making another mistake by importing
>> another patched up tool to deal with another one "non-binary format"
>> for any kind of data.
>
> "Patched-up"? By no means are my tools perfect, but since nobody has
> bothered to comment, I can only assume there's not much to
> say. Though, if you've got something to say, please go ahead and say
> it. But please keep it technical. And I would also kindly ask you to
> refrain from gratuitously insulting other people's work.

No offense, but you're repeating the same mistake many other writers do.
You assume that whatever is done, is ready to become accepted by the world.
It isn't so. Instead, anything with insufficient grounds is considered
patched up, and the quality of work doesn't matter at all.

I don't see how your tool is useful in large, and proof-of-concept examples
don't convince me. I've seen enough of them. The world moved from binary data
representation to textual one and now we see opposite moves in various
faster CGI replacements and some other protocols.

I don't see how it will simplify doing my regular tasks potential ones
included, since most of databases are still plain text files.
And instead of converting them into XML I'd like to have real directory
service or DBMS, e.g. SQLite, I'm consent even if it is Berkeley DB style
key--value storage. What's XML use, if one would rather learn LDIF or SQL
instead?

>> This is wrong approach. If you think that a tool is useful,
>> make a package and popularize it.
>
> Will do. This does not prevent it from being imported into base,
> though.

This is necessary condition. We have more useful software blocked
outside base, e.g. Lua, and xmlgrep isn't as useful as Lua is.
Promote your tools, make them popular and useful, and it will be fine.
As for now I find grounds to import it into base system at least
insufficient and oppose importing.


-- 
HE CE3OH...