Is there a way to create a type alias in protobuf

Is it possible to create aliases of protobuf's scalar types?

For example, I'd like to use Sequence in lieu of string, even though they would be binary equivalent.

My immediate goal is to make documentation (generated with protoc-gen-doc) more readily understandable.

Ideally, this type would be represented in languages that support type checking, but that's not necessary.

回答1:

Well this will be a bit dull answer but:

No, I'm not aware of such feature existing or having been planned.

You can sort of emulate it by making submessages that contain only a single field, but that will alter the binary representation.

You're not the first asking this though:

Re: [protobuf] does protoc allow you to typedef a scalar ?
Is it possible to define an alias for type (enum or message) in google protobuf?

回答2:

[Update: Aug 2017. Adapted to the full Go rewrite of protoc-gen-bug, currently 1.0.0-rc]

I don't have an answer for type aliases, but do have one for this:

My immediate goal is to make documentation (generated with protoc-gen-doc) more readily understandable.

And also I want to point out that protoc-gen-doc has been entirely rewritten in Go and now uses Docker for generation instead of apt-get.

I have created some html and markdown demo's of using inline rich formatting within your comments, like adding links, code snippets, tables, bold, italic, etc.

And also describe how you can auto-generate and publish to Github Pages (gh-pages branch) using TravisCI

There are some small bugs that still need to be solved (Aug 2017) for it to be production-ready.

View the demo's + description at:

https://github.com/aschrijver/protoc-gen-doc-example

For example having markdown inlined comments like these:

/**
* The **SLEEP** format is designed by the [Dat Project](https://datproject.org) 
* to allow for sparse replication, meaning you can efficiently download
* only the metadata and data required to resolve a single byte region 
* of a single file, which makes Dat suitable for a wide variety of streaming,
* _real-time_ and large dataset use cases.
*
* To take advantage of this, Dat includes a _network protocol_. It is message
* based and stateless, making it possible to implement on a variety of network
* transport protocols including UDP and TCP.
*
* Both metadata and content registers in **SLEEP** share the exact same
* replication protocol.
*
* Individual messages are encoded using Protocol Buffers and there are ten
* message types in total.
*
* ### Wire Protocol
*
* Over the wire messages are packed in the following lightweight
* container format:
*
* ```
* <varint - length of rest of message>
*   <varint - header>
*   <message>
* ```
*
* The `header` value is a single `varint` that has two pieces of information,
* the integer type that declares a 4-bit message type (used below), and a
* channel identifier, 0 for metadata and 1 for content.
*
* To generate this varint, you bitshift the 4-bit type integer onto the end of
* the channel identifier, e.g. channel << 4 | <4-bit-type>.
*
* ### Using in NodeJS
*
* The `protocol-bufers` package offers an intuitive javascript API, so you need
* not worry about low-level protocol concepts.
* 
* This example demonstrates how you create a feed and start streaming:
*
* ```javascript
*   var protocol = require('hypercore-protocol')
*   var stream = protocol()
*   
*   // open a feed specified by a 32 byte key
*   var feed = stream.feed(Buffer('deadbeefdeadbeefdeadbeefdeadbeef'))
*   
*   feed.request({block: 42})
*   feed.on('data', function (message) {
*     console.log(message) // contains message.index and message.value
*   })
*   
*   stream.pipe(anotherStream).pipe(stream)
* ```
*/

Will result in output similar to this:

HypercoreSpecV1_md.proto

The SLEEP format is designed by the Dat Project to allow for sparse replication, meaning you can efficiently download only the metadata and data required to resolve a single byte region of a single file, which makes Dat suitable for a wide variety of streaming, real-time and large dataset use cases.

To take advantage of this, Dat includes a network protocol. It is message based and stateless, making it possible to implement on a variety of network transport protocols including UDP and TCP.

Both metadata and content registers in SLEEP share the exact same replication protocol.

Individual messages are encoded using Protocol Buffers and there are ten message types in total.

Wire Protocol

Over the wire messages are packed in the following lightweight container format:
<varint - length of rest of message>
  <varint - header>
  <message>
The header value is a single varint that has two pieces of information, the integer type that declares a 4-bit message type (used below), and a channel identifier, 0 for metadata and 1 for content.

To generate this varint, you bitshift the 4-bit type integer onto the end of the channel identifier, e.g. channel << 4 | <4-bit-type>.

Using in NodeJS

The protocol-bufers package offers an intuitive javascript API, so you need not worry about low-level protocol concepts.

This example demonstrates how you create a feed and start streaming:
var protocol = require('hypercore-protocol')
var stream = protocol()

// open a feed specified by a 32 byte key
var feed = stream.feed(Buffer('deadbeefdeadbeefdeadbeefdeadbeef'))

feed.request({block: 42})
feed.on('data', function (message) {
  console.log(message) // contains message.index and message.value
})

stream.pipe(anotherStream).pipe(stream)

(Note: The hypercore protocol is one of the core specifications of the Dat Project ecosystem of modules for creating decentralized peer-to-peer application designs. I used their .proto file to demonstrate concepts)