Re: fs-independent quotas (binary plists)
On Thu, Nov 17, 2011 at 06:45:01PM -0500, Julio Merino wrote: | On 11/17/11 1:07 PM, David Young wrote: | I do think that a binary plist format would be a handy option, however, | a binary plist is not as useful by itself as an XML plist, because there | less that you can do to it without specialized tools. | | This may be completely out of topic, but I just though of mentioning | Google's Protocol Buffers. These seem to serve a similar purpose to | proplib. Protocol Buffers, or protobufs for short, are, in my opinion, | much simpler to represent in their textual form and they can be | converted to a very compact binary form for serialization. | | For more details: | | http://code.google.com/p/protobuf/ | | They don't have a C interface (only C++), but I don't think it'd be that | hard to add one :-P I used these recently in a work project, and will again in the future. The language for declaring the spec is pretty usuable, the compiler (from spec - C++ bindings) is quick, and the transcoders seemed stable enough. My main complaint with them is the lack of inbuilt framing for transmission over byte-oriented transports; you have to roll your own but that's trivial. Luke. pgpmgomjXbeAF.pgp Description: PGP signature
Re: fs-independent quotas (binary plists)
On Thu, 17 Nov 2011 10:50:17 +0100 Manuel Bouyer bou...@antioche.eu.org wrote: In this context, text format means a key/value pair format, in which some keys are optionnal and values can be of arbitrary types. Maybe you can do this with a binary format too, but it doesn't exists yet. This reminds me that years ago someone implemented support to save plists in a binary format[1] (this doesn't necessarily mean that it would help solve this problem, though). But I'm surprised that since all these years the support wasn't added; anyone know if there is general resistance to an optional compact and portable binary format, and if so, the reasons? If such a format was supported, it wouldn't be harder to machine or human-process (proplib could be used as it is now for code, and bplists could be easily exported to an xml format as requested to edit in an editor, i.e. via a viplist, plistctl or such command (which also could use advisory locking, of course, and save back to binary format if the system is configured to use a binary format). In theory, it could also increase performance, and a binary format would be simpler to parse by the kernel than xml, minimizing bugs... [1] ftp://ftp.netbsd.org/pub/NetBSD/misc/freza/bplist-2007-10-27.diff Thanks, -- Matt
Re: fs-independent quotas (binary plists)
On Thu, Nov 17, 2011 at 05:22:24AM -0500, Matthew Mondor wrote: On Thu, 17 Nov 2011 10:50:17 +0100 Manuel Bouyer bou...@antioche.eu.org wrote: In this context, text format means a key/value pair format, in which some keys are optionnal and values can be of arbitrary types. Maybe you can do this with a binary format too, but it doesn't exists yet. This reminds me that years ago someone implemented support to save plists in a binary format[1] (this doesn't necessarily mean that it would help solve this problem, though). But I'm surprised that since all these years the support wasn't added; anyone know if there is general resistance to an optional compact and portable binary format, and if so, the reasons? You know, I *thought* that there was general resistance to a binary format because it had been repeated so often, but recently I re-read the actual discussion that occurred and it seemed that there was *not* much resistance at all. I think that sometimes people bring up prior absolute prohibitions or intractable resistance because they are too easily discouraged or else they don't want to argue an issue on its merits. If such a format was supported, it wouldn't be harder to machine or human-process (proplib could be used as it is now for code, and bplists could be easily exported to an xml format as requested to edit in an editor, i.e. via a viplist, plistctl or such command (which also could use advisory locking, of course, and save back to binary format if the system is configured to use a binary format). In theory, it could also increase performance, and a binary format would be simpler to parse by the kernel than xml, minimizing bugs... I do think that a binary plist format would be a handy option, however, a binary plist is not as useful by itself as an XML plist, because there less that you can do to it without specialized tools. I have said it before, but I would hate to see further reduplication of editors in UNIX, and that includes a plist editor. We need a way to compose filters with editors! Dave -- David Young dyo...@pobox.comUrbana, IL(217) 721-9981
Re: fs-independent quotas (binary plists)
On 11/17/11 1:07 PM, David Young wrote: I do think that a binary plist format would be a handy option, however, a binary plist is not as useful by itself as an XML plist, because there less that you can do to it without specialized tools. This may be completely out of topic, but I just though of mentioning Google's Protocol Buffers. These seem to serve a similar purpose to proplib. Protocol Buffers, or protobufs for short, are, in my opinion, much simpler to represent in their textual form and they can be converted to a very compact binary form for serialization. For more details: http://code.google.com/p/protobuf/ They don't have a C interface (only C++), but I don't think it'd be that hard to add one :-P -- Julio Merino / @jmmv
