Jblink (https://github.com/pantor-engineering/jblink)

[Anders Furuhed]

We have had a couple of face to face discussions on jblink in the last few weeks. You are welcome to discuss Blink and jblink over a cup of coffee in our office, but it would also be great to have an open discussion here.

As soon as we find the time, we are going to write blog posts introducing jblink in some more detail. If you have questions, comments, or review feedback, feel free to post here or start another topic.

[Anders Furuhed]

Damian,

the blinkc tools can be used to do that, for the generation of static interfaces. In the codec run time, the primary question is the internal layout that messages are decoded into and encoded from. For any JVM based language, I guess that jblink would function as a common codec. For many languages, the best option could be to share a codec written in C/C++ delivering messages on the heap and allowing access using foreign function interfaces.

7 jun 2013 kl. 23:07 skrev Damian Gryski <dgr...@gmail.com>:

Le lundi 3 juin 2013 18:53:22 UTC+2, Anders Furuhed a écrit :

We have had a couple of face to face discussions on jblink in the last few weeks. You are welcome to discuss Blink and jblink over a cup of coffee in our office, but it would also be great to have an open discussion here.

As soon as we find the time, we are going to write blog posts introducing jblink in some more detail. If you have questions, comments, or review feedback, feel free to post here or start another topic.

How easy would it be to extract the replace the code-generation pieces of the java implementation?  For example, the Apache Thrift shares the same front-end code for parsing the schema definitions, but pluggable backends (all in java) generate the client code in the various languages.

Damian 

--
You received this message because you are subscribed to the Google Groups "The Blink Protocol" group.
To unsubscribe from this group and stop receiving emails from it, send an email to the-blink-proto...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/the-blink-protocol/5da7a27e-d347-482e-aa88-563edbdfc4cb%40googlegroups.com?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Damian Gryski]

Le dimanche 9 juin 2013 00:26:38 UTC+2, Anders Furuhed a écrit :

Damian,

the blinkc tools can be used to do that, for the generation of static interfaces. In the codec run time, the primary question is the internal layout that messages are decoded into and encoded from. For any JVM based language, I guess that jblink would function as a common codec. For many languages, the best option could be to share a codec written in C/C++ delivering messages on the heap and allowing access using foreign function interfaces.

   My interest would be in implementing a pure Go backend, rather that one that wraps a C++ implementation -- it would probably be easier anyway.

   Damian 

[Anders Furuhed]

Ok, got it!

It would be great to have a native Go implementation of Blink.

I suggest starting out with having a look at blinkc and write a Go interface generator. We have yet to write a blog entry explaining blinkc in more detail. The output of blinkc is primarily of use to the application programmer and not to the codec itself, or it would become more static than what is ideal.

On the codec side, it would be interesting to see if the jblink implementation techniques forms a pattern that can be applied to a Go codec, i.e. that the codec is using reflection and other native language / vm features to be fully dynamic.

The first two documents I found was http://golang.org/doc/articles/laws_of_reflection.html and http://research.swtch.com/interfaces. 

What are your thoughts on this?

We would be very happy to help out but have little Go experience yet.

[Damian Gryski]

On Sun, Jun 9, 2013 at 10:30 AM, Anders Furuhed <anders....@pantor.com> wrote:

Ok, got it!

It would be great to have a native Go implementation of Blink.

I suggest starting out with having a look at blinkc and write a Go interface generator. We have yet to write a blog entry explaining blinkc in more detail. The output of blinkc is primarily of use to the application programmer and not to the codec itself, or it would become more static than what is ideal.

On the codec side, it would be interesting to see if the jblink implementation techniques forms a pattern that can be applied to a Go codec, i.e. that the codec is using reflection and other native language / vm features to be fully dynamic.

The first two documents I found was http://golang.org/doc/articles/laws_of_reflection.html and http://research.swtch.com/interfaces. 

What are your thoughts on this?

We would be very happy to help out but have little Go experience yet.

Go has good reflection support, and my implementation of the Sereal serialization protocol ( https://github.com/Sereal/Sereal ) is entirely based around reflection.  Sereal is schemaless (like msgpack), so any implementation requires being able to construct types on the fly.  However, reflection is much slower than natively-typed code so my preferred implementation for Blink would be a hybrid approach: ahead-of-time compilation like protobufs, but with support for loading schemas at runtime.  My first goal would be to get the code-generation pieces done because that doesn't require reimplementing the entire schema parsing logic.  Then, a Go-based schema parser would be written to allow runtime schema loading.  Finally, the codegen pieces would be rewritten to use the new Go schema parser.   (This is all still very hypothetical -- I don't need this for $WORK and my free time is limited these days.)

Damian