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,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.
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.