MPWA

[Jeremy Lavergne]

Stick to using a language that you know. Best option is one that lines up with the rest of our online codebase.

"livinded" <livinded at deadbytes.net> wrote:

>Having not used Ramaze I can't comment on it as a framework in terms of features, stability, speeds, performance, etc. I have looked into Sinatra briefly but have not done any realy development using it. I like Sinatra and definitely believe that it has it's place, but I believe that Rails is better fit for this project. 
>
>Sinatra is good for smaller projects or where the Rails convention (REST, routing, default db layer, etc.) does not do what is needed for an application. Since Rails 2.x a lot of this functionality has been added to Rails and should not be a concern for this application.
>
>In regard to the fact that both are smaller and faster I would question whether or not there is a valid concern that rails will not be able to scale to the needs of the application. In terms of Sinatra, there is no scaffolding or convention which means that there will be more work in the actual development and that it will take more work for other developers to become familiar with the code base.
>
>Rails is a well tested framework and has run major sites and applications such as Twitter with a large and active community of developers. The fact that MPWA will unlikely have anywhere near the traffic and nowhere near the amount of backend processing that something like Twitter requires, I don't forsee any of the scaling issues to be a problem. Using better performing ruby interpreters such as YARV and technology such as Phusion's Passenger, Rails is able to scale much higher than in the past, not to mention the performance improvements coming in Rails 3.
>
>While Ramaze and Sinatra may be smaller and faster the real question is whether or not the performance increase is going to be significant and if that is really needed. Rails will be able to perform well enough for this application and the benefits such as, existing gems, convention, and that it's well tested outweigh the fact that Sinatra or Ramaze might perform slightly better, especially in a situation where the performance may not even be significant.
>On Apr 13, 2010, at 12:33 PM, Dmitry Gorbik wrote:
>
>> I would propose using Sinatra or Ramaze instead of RoR. Smaller and faster. What are your thoughts about that?
>> 
>> 2010/4/7 livinded <livinded at deadbytes.net>
>> I've been reading over the code and, aside from a few modifications, there really isn't much there other than the default scaffolding that rails creates for you. I'd definitely use what's there as a base, but it would probably be simpler to simply scaffold everything using a newer version of rails and just porting all of the actual changes to the new code base.
>> On Apr 6, 2010, at 1:16 AM, Rainer Müller wrote:
>> 
>> > Hello Joe,
>> >
>> > On 2010-04-06 05:29 , livinded wrote:
>> >> I've been looking over the MPWA project for the GSoC and am
>> >> interested in working on it. After checking out the code base and
>> >> attempting to get it up and running to test out, I realized that it
>> >> was written using Rail 1.x which is almost two major revisions
>> >> behind. After a number of modifications I was able to get the code
>> >> base running on 2.3.5 somewhat and was able to actually test it out.
>> >
>> > It is nice that you got so far. As the code is old as you say, you are
>> > not tied to use ruby on rails or any of the existing code. If you think
>> > porting to a newer version would be more work than a rewrite, that's
>> > okay. Propose and use what you think would be the best tools for this task.
>> >
>> >> Looking at the TODO list there in the subversion repo there really
>> >> didn't seem like there was all that much, featurewise, to do other
>> >> than add in user/role authorization, commenting, and minor changes to
>> >> the view. Based on the current code base I see there being two major
>> >> portions of this project, the first being to update the code base to
>> >> use a newer version of rails, either 2.x or 3-beta, and secondly
>> >> adding in new functionality. I know that the code base is fairly old
>> >> and was wondering what else such as integration with Trac or other
>> >> systems that MacPorts uses or other features that should be added
>> >> into it?
>> >
>> > MPWA should be able to be a comprehensive online interface to the ports
>> > tree. List which ports are available (with a search function of course)
>> > in a appealing way. It should also include links to tickets filed
>> > against a port. Maybe it could also have some rating/comment system.
>> >
>> > Decide yourself which features are possible and how. You could compare
>> > to already existing websites for other distribution systems
>> > (packages.debian.org, packages.gentoo.org, freshports.org to name a few).
>> >
>> > Rainer
>> > _______________________________________________
>> > macports-dev mailing list
>> > macports-dev at lists.macosforge.org
>> > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
>> 
>> _______________________________________________
>> macports-dev mailing list
>> macports-dev at lists.macosforge.org
>> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
>> 
>
>_______________________________________________
>macports-dev mailing list
>macports-dev at lists.macosforge.org
>http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev