thrift-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bryan Duxbury <br...@rapleaf.com>
Subject Re: Some thoughts about changes to Thrift
Date Fri, 06 Mar 2009 19:53:34 GMT
Should the goal be matching up with stuff that's already installed,  
or just that when you have to install something, it's easy to do?  
Right now, we can't do Windows because it's *impossible* for our code  
to run on that architecture due to lack of libraries. Any other  
language that runs well on a lot of platforms (Java, Ruby, Python...)  
would be fine if our only goal is cross-platform capabilities.

If we do care about whether everything is preinstalled, then I'll  
throw out a vote for Ruby, just because it's my favorite option. Ruby  
is often distributed with Linux and OSX, and easy to install on  
WIndows and elsewhere.

-Bryan

On Mar 6, 2009, at 11:36 AM, Mark Slee wrote:

> I do just want to call out again here that AFAIK Java tends not to  
> be distributed with many flavors of Linux, whereas Python does.
>
> If a rewriting effort is undertaken, I'd just throw out a big +1 to  
> fullly considering Python in addition to Java.
>
> -----Original Message-----
> From: Rush Manbert [mailto:rush@manbert.com]
> Sent: Friday, March 06, 2009 10:01 AM
> To: thrift-user@incubator.apache.org
> Subject: Re: Some thoughts about changes to Thrift
>
> I don't use any command line tools that are Java-based, so I'm  
> speaking from lack of experience here. :-)
>
> IMHO, a major feature of any tool implementation is that it be easy  
> to integrate into user's build environments on all supported  
> platforms.
> In my case, this means that I need use the tool from a Xcode  
> project and also from a Visual Studio project. When we eventually  
> support Linux, then I guess I'l need to use in a big Makefile-based  
> set of projects. It may mean that I need to write appropriate  
> makefiles and use the make-flavor of project that Xcode and VS  
> support. On the Mac, in particular, this is important because I can  
> make my library project that uses Thrift depend on the project that  
> generates the sources using the compiler.
>
> So what I'm saying is please take this into consideration when  
> picking the cross-platform language to use for rewriting the  
> compiler. My personal choice would be Python, because it's nice and  
> clean to use from the command line, there are template engines  
> available for it, and installing Python on Windows is pretty easy.  
> But if a Java-based tool has all the same characteristics, then go  
> for it.
>
> - Rush
>
> On Mar 6, 2009, at 8:02 AM, Bryan Duxbury wrote:
>
>> It seems like there's some consensus on a JavaCC based compiler.
>> Should we open an JIRA issue and start to explore feasibility?
>> -Bryan
>>
>> On Mar 6, 2009, at 3:03 AM, Esteve Fernandez wrote:
>>
>>> On Friday 06 March 2009 03:24:23 Mark Slee wrote:
>>>> That's pretty much my fault.
>>>
>>> Actually the current Thrift compiler served its puporse quite
>>> decently, but the coming of new languages and features has made it
>>> (along with the
>>> generators) a bit more complex and less easy to maintain.
>>>
>>>> I personally like Java and think it'd be a decent choice, but there
>>>> do seem to be a decent number of people out there building services
>>>> who seem to vehemently hate Java. Lots of *nix systems do not  
>>>> have a
>>>> JVM or JDK installed by default -- and it's pretty annoying for
>>>> users who aren't writing services in Java to have to install it to
>>>> build the compiler.
>>>
>>> I'd argue for writing a parser in Java and use a template engine
>>> (Velocity, Freemarker, etc.). Why not Python? Dunno :-) I think Java
>>> is more widely deployed, it has better tools for scanning and  
>>> parsing
>>> and more developers.
>>> Etch, another incubating project with similar goals to Thrift, uses
>>> JavaCC for parsing and Velocity as template engine for its compiler
>>> and generators, even though it also emits C#
>>>
>>> Using a template engine would make development of new features and
>>> the inclusion of more languages much easier. Instead of having to
>>> hack a generator to add some new feature, we could simply supply a
>>> new template file. For example, at some point in the future I'd like
>>> to build a generator for Javascript, and if we used a template
>>> engine, it would be a matter of writing a minimal generator and a
>>> bunch of templates.
>>>
>>> Cheers.
>


Mime
View raw message