Hello!
Nice, I will have a look.
I am interested to see how class layouts / slots can be used here.
(but it might take some days to find time…)
Marcus
> On 26 Feb 2019, at 07:54, Holger Freyther <hol...@freyther.de> wrote:
>
> Hi,
>
> from my point of view the pillars of future services are Google protobuf[1]
> and gRPC. Protobuf can be used for configuration files[2], tracing/logging[3]
> and storage[4]. gRPC is built on top-of HTTP2 and is using the protobuf IDL
> and marshaling. Many projects (etcd, envoy, Google Cloud, ...) provide a gRPC
> based API (and some automatically map this from REST to gRPC) already and I
> would like to build clients and servers in Pharo.
>
>
> My plan of action is to start with a protobuf compiler/model and then look
> into binding the gRPC C implementation to Pharo.
>
>
> I have started with gokr's Protobuf code on Smalltalkhub and defined base
> types and a Slot and could use some help to structure this more nicely.
>
> The code is at: https://github.com/zecke/pharo-protobuf and I could use some
> comments/review of how to use Slots in a significant way (add "type"
> validation on write, constraint checks, builder pattern?).
>
> Given a definition like:
>
> syntax = "proto2";
> package foo;
> enum Color {
> RED = 0;
> GREEN = 1;
> BLUE = 2;
> }
> message MyMessage {
> optional Color color = 1;
> }
>
> And an encoded binary message of #[8 2] the following can:
>
> PBTestMessage materializeFrom: #[8 2] readStream
>
>
> decode and set the color field. Proper handling of mandatory and repeated
> fields are missing and decoding the other values, nested messages... :)
>
>
>
> Looking forward to have some eyes on the code.
>
> holger
>
>
>
>
>
> [1] A simple IDL to define structs/enums with marshaller/materializer for a
> binary protocol, JSON (and yaml).
>
> [2] Without having to write a XML/JSON schema and getting validation from the
> IDL.
>
> [3] Many of us log structured to text, then have something like logstash to
> re-parse, regexp it and dump it into ElasticSearch. With protobuf we can have
> plain objects end to end for logging.
>
> [4] We have FUEL so this is less interesting for us than others but quite
> interesting if you are mixing Pharo with other implementation languages.
