Eh, they're a marshaling format, we need an in-memory layout, and we
might as well make the two the same.
On Fri, Dec 12, 2008 at 4:29 AM, Keunwoo Lee keun...@chromium.org wrote:
Protocol buffers are now open source. Why not use them as the storage
format?
~k
On Mon, Dec 8, 2008 at 10:40
Protocol buffers are now open source. Why not use them as the storage
format?
~k
On Mon, Dec 8, 2008 at 10:40 AM, Evan Martin e...@chromium.org wrote:
- Is the plan to mmap the data file directly? Avoids copies, but
means we should (a) null terminate the string resources (maybe the rc
- Is the plan to mmap the data file directly? Avoids copies, but
means we should (a) null terminate the string resources (maybe the rc
format does this already) and (b) sort the resource entries by
resource id for faster lookup.
- We should make explicit the byte order for the int32s. We can't
On Mon, Dec 8, 2008 at 10:40 AM, Evan Martin [EMAIL PROTECTED] wrote:
- Is the plan to mmap the data file directly? Avoids copies, but
means we should (a) null terminate the string resources (maybe the rc
format does this already) and (b) sort the resource entries by
resource id for faster
All good points. I've added notes about null terminating the strings,
little endian byte order, and utf8 encoding.
zip or zlib or bzip compression may speed load time. I'm not sure, but I
think that would be an iteration we add later. It probably wouldn't help
with the theme .so file, but it
Fast question, have you think about adding checksum?
On Dec 8, 12:15 pm, [EMAIL PROTECTED] wrote:
I wrote a short design doc about handling data resources and localized
strings on linux.
http://sites.google.com/a/chromium.org/dev/developers/design-document...
Feedback welcome.
tony