> Enable new ways of working together - Fragmentation is a chronic barrier in the pursuit of software that meets people's needs. Creating interoperable foundations can unlock new freedoms and creativity.
This grand declaration is followed by a pretty complex serialization format. Given the complexity, it's highly likely it will only ever have one implementation. Given the high number of pre-defined types, it also expects reader to have comprehensive type libraries -- if your language/library does not support specific type for "j part of quaternion numbers" or "month part of the date", it's not going to be able to deserialize every message.
Protocols full of pre-defined types are great if you are working within a company, but they will never going to create interoperable foundations. For those, you want a very basic protocol with very basic types, and an extensible metadata system.
Think JSON with JSON-schema, or Protobuf, or Apache Avro or many others... All of those have great property: a naive client who has no idea what "quaternion" is can still access the data - copy, display to users, pass to others... While the more advanced clients can create proper types for ease of access.
pierogitus•3mo ago
Hey theamk, thanks for the in-depth comment.
> it's highly likely it will only ever have one implementation
Yes, many implementations is the intent.
> very basic types, and an extensible metadata system
I would argue DBUF does satisfy this statement. The symbols compose in a way that separates the structure from the meaning. A parser doesn't need to know what a quaternion is, it would only see it as a map with 4 fields. If a parser understands the first 16 symbols in the registry, it can parse any message. All other symbols are encoded in a predetermined way.
I'd appreciate any thoughts on how the docs are not making those concepts clear.
theamk•3mo ago
> Ideals
> Enable new ways of working together - Fragmentation is a chronic barrier in the pursuit of software that meets people's needs. Creating interoperable foundations can unlock new freedoms and creativity.
This grand declaration is followed by a pretty complex serialization format. Given the complexity, it's highly likely it will only ever have one implementation. Given the high number of pre-defined types, it also expects reader to have comprehensive type libraries -- if your language/library does not support specific type for "j part of quaternion numbers" or "month part of the date", it's not going to be able to deserialize every message.
Protocols full of pre-defined types are great if you are working within a company, but they will never going to create interoperable foundations. For those, you want a very basic protocol with very basic types, and an extensible metadata system.
Think JSON with JSON-schema, or Protobuf, or Apache Avro or many others... All of those have great property: a naive client who has no idea what "quaternion" is can still access the data - copy, display to users, pass to others... While the more advanced clients can create proper types for ease of access.
pierogitus•3mo ago
> it's highly likely it will only ever have one implementation
Yes, many implementations is the intent.
> very basic types, and an extensible metadata system
I would argue DBUF does satisfy this statement. The symbols compose in a way that separates the structure from the meaning. A parser doesn't need to know what a quaternion is, it would only see it as a map with 4 fields. If a parser understands the first 16 symbols in the registry, it can parse any message. All other symbols are encoded in a predetermined way.
I'd appreciate any thoughts on how the docs are not making those concepts clear.