Coder Social home page Coder Social logo

b's People

Contributors

unwriter avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar

b's Issues

Support for both 'content-encoding' and 'character-encoding'

The 'encoding' field for specifying the character encoding is being overloaded in the wild to support content-encoding since no field exists for this specific purpose.

Here is an example tx which uses gzip compression on an html:
image

The encoding field is being used to specify the content-encoding gzip. This information is required to decode and render the content. While many content types are specific enough to include the compression information, many common content types are not such as text/html.

This issue is avoided in practice by overloading 'encoding' to define both types since knowing the content-encoding (gzip) can help you assume a binary character encoding, but this may not be safe in all cases in the future. You can imagine scenarios where some data might be compressed but with a resulting character encoding other than binary / converted to some other character encoding afterwards for some reason. This would be impossible to express in B's current form.

In my case, I am writing a TXO parser that relies on the value in the 'encoding' field to dictate which pushdata should be used for this content (out.b(x) vs out.s(x)). If the value is 'gzip' or similar, the "correct" thing to do according to the spec would be to produce an error as this is not a valid character-encoding. I cannot make a reliable determination without assuming the character encoding.

According to the docs, one design goal of B was to be both:
Simple: Simple to implement
Extensible: Future extensibility with additional push data support

With this in mind, I propose adding an additional optional field for 'content-encoding'. This would be added after filename as to be backward compatible. If omitted, it should be assumed to have a value of 'identity', i.e. no additional compression or modification. If there is no compression, no changes are required for application developers writing B content to the chain. If there is compression, you must specify the content encoding as well as the character encoding.

The results would look like this:

OP_RETURN
  19HxigV4QyBv3tHpQVcUEQyq1pzZVdoAut
  [Data]
  [Media Type]
  [Character Encoding]
  [Filename]
  [Content Encoding]

Another example:
OP_RETURN 19HxigV4QyBv3tHpQVcUEQyq1pzZVdoAut [ArrayBuffer from the file] text/html binary index.html gzip

The only alternative I can think of other than defining a new protocol is:

  • If the character encoding is not a valid type, assume it is binary and use the value instead to define content-encoding.

My problem with this is, it has a potential to break in the future and is not really "simple" since you would need to know this and its not immediately obvious.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.