Switch to binary format and more. #38
Comments
|
If you are moving to a binary format - why not use an existing one instead
of inventing yet another one?
…On Fri, Feb 10, 2017 at 8:43 PM, Dmitry Titov ***@***.***> wrote:
Hi,
Capturing recent conversations with @jyasskin
<https://github.com/jyasskin> and @mrdewitt <https://github.com/mrdewitt>:
1. We think it makes sense to switch to 100% binary format since the
header compression and parts body compression makes it mostly binary
anyways. It also lets us to replace MIME boundary strings with direct
chunk-size kind of encoding.
2. The Explainer and samples in it will be gradually updated to
reflect switch to binary encoding. While in update, there can be some
inconsistency in the doc.
Also discussed:
- Binary alignment at 32 bit boundaries (decided not to)
- Use Self-Delimiting Numeric Values (rfc 6256) (decided not to)
- Split content index and offset table (so the resources may be
rearranged)
- Multiple hashes (to support deprecation of old ones)
- Cross-signing
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#38>, or mute the thread
<https://github.com/notifications/unsubscribe-auth/AE1vNVOpv6nACGgd-JbgukU8oqFXpRHLks5rbRJegaJpZM4L-CAb>
.
|
|
@lrosenthol Which existing one? Note the considerations at https://github.com/w3ctag/packaging-on-the-web#rejected-approaches |
|
CBOR looks interesting. It seems to support streaming on receiving end as well. |
|
CBOR does look interesting, but seems to be more focused on handling a
single file and not a package/collection of files & resources. I think we
need a more classic archiving format - something like a ZIP or StuffIt -
but with modern sensibilities. I'll do some research
…On Wed, Feb 15, 2017 at 4:01 PM, Dmitry Titov ***@***.***> wrote:
CBOR looks interesting. It seems to support streaming on receiving end as
well.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#38 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AE1vNRW1nXyJEUNjLiSLLVF6OohBQ-jEks5rc2e6gaJpZM4L-CAb>
.
|
|
There are 2 orthogonal things - binary encoding and then an index/manifest/hashing structure. Formats like CBOR provide the former w/o attempting to provide the latter. So if we want specific structure and content of the package metadata (index, manifest, certificates and hashes), and don't care much about the way to assemble those pieces into a binary file with chunks of certain size is not important. The main issue with Zip and other archiving formats is they mostly were developed without streaming on receiving and with fixed and/or limited set of metadata, and they will have to be 'augmented' in one way or another. CBOR seems to be a simple way to assemble length-prefixed and variable-length records, arrays and maps, and supports variable-length numbers, byte blobs and UTF-8 strings. No notion of a directory or hashing, which seems to be a good thing since those are exactly the subject of this proposal. |
|
It is small potatoes, but CBOR has already got debug tools and pretty
printers, so we'd have a head start on tooling as well.
…On Thu, Feb 16, 2017 at 9:58 AM Dmitry Titov ***@***.***> wrote:
There are 2 orthogonal things - binary encoding and then an
index/manifest/hashing structure. Formats like CBOR provide the former w/o
attempting to provide the latter. So if we want specific structure and
content of the package metadata (index, manifest, certificates and hashes),
and don't care much about the way to assemble those pieces into a binary
file with chunks of certain size is not important.
The main issue with Zip and other archiving formats is they mostly were
developed without streaming on receiving and with fixed and/or limited set
of metadata, and they will have to be 'augmented' in one way or another.
CBOR seems to be a simple way to assemble length-prefixed and
variable-length records, arrays and maps, and supports variable-length
numbers, byte blobs and UTF-8 strings. No notion of a directory or hashing,
which seems to be a good thing since those are exactly the subject of this
proposal.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#38 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABQXzu8O_nbEWIOoQ7krTnKr6ERfmEWMks5rdI4zgaJpZM4L-CAb>
.
|
|
Fixed by #36. |
Hi,
Capturing recent conversations with @jyasskin and @mrdewitt:
Also discussed:
The text was updated successfully, but these errors were encountered: