[stringtemplate-interest] visualizer mockup

[Todd Stout]

I should point out that protobuf does not provide an actual transport out of
the box.  Several projects outside of google provide this.  I'm using my own
async socket library at the moment.  If you are thinking that you get a full
net layer from protobuf, that's not the case.  Google's not releasing
whatever they use.  I guess they consider that part of their secret sauce.
 What is released by Google is a just the data serialization implementation
and some damn good documentation.

On Tue, Nov 24, 2009 at 8:31 PM, Todd Stout <todd.tstout at gmail.com> wrote:

> I have just started using protobuf for some personal work that I plan to
> eventually make open source.  The only reason I went with protobuf was that
> it had the best documentation and supports the languages I care about at the
> moment.  In addition, given that its origins involve Google, it is likely to
> still be known by developers 10 years down the road. Depending on your
> requirements, other options such as Thrift might be better.
>
>
> On Tue, Nov 24, 2009 at 7:42 PM, Gerald Rosenberg <gerald at certiv.net>wrote:
>
>> Yes, the sockets aspect is more a proxy for discussing the fact that
>> the ST instance, executing in its own process, needs to communicate
>> with the tool in a language neutral manner.
>>
>> I would prefer something more high level than sockets.  Google
>> Protocol Buffers (BSD) and Facebook Thrift (Apache) are
>> possibilities.  There are others (Etch, Avro, etc), but the practical
>> choice appears to be between PB (better documentation) and Thrift
>> (more bindings).
>>
>> @Todd, or anyone else, do you have a recommendation?
>>
>> http://stuartsierra.com/2008/07/10/thrift-vs-protocol-buffers
>>
>> http://timyang.net/programming/thrift-protocol-buffers-performance-2/
>>
>>
>> At 04:47 PM 11/24/2009, Barrie Treloar wrote:
>> >On Wed, Nov 25, 2009 at 5:03 AM, Terence Parr <parrt at cs.usfca.edu>
>> wrote:
>> > > Oh, and another architectural issue.  Should this be a socket
>> > based thing like ANTLRWorks so C# and Python targets don't have to
>> > build their own GUI?  I'd say yes, but then it's harder to drill
>> > down into objects in the attribute table.  I'll have to YAML or
>> > JSON marshall objects across the socket.  Some objects like binary
>> > arrays might be hard to represent properly in language indep manner in
>> gui too.
>> >
>> >I think some of the discussion so far raised some misunderstandings.
>> >
>> >Is this meant to be a static inspection of the template? i.e some
>> >meta-data about template generation - which either resides inside the
>> >template or perhaps in another source (file, socket stream, etc)
>> >
>> >Or is this meant to be something dynamic so that as the template is
>> >generated you can see what is going on?
>> >
>> >My understanding so far has been that this would be static inspection.
>> >And if so I am unclear what a socket implementation would provide.
>> >_______________________________________________
>> >stringtemplate-interest mailing list
>> >stringtemplate-interest at antlr.org
>> >http://www.antlr.org/mailman/listinfo/stringtemplate-interest
>>
>> _______________________________________________
>> stringtemplate-interest mailing list
>> stringtemplate-interest at antlr.org
>> http://www.antlr.org/mailman/listinfo/stringtemplate-interest
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.antlr.org/pipermail/stringtemplate-interest/attachments/20091124/b781e6d5/attachment.html