[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Savannah-hackers-public] Porting Savane to Perl: A proof of concept

From: Assaf Gordon
Subject: Re: [Savannah-hackers-public] Porting Savane to Perl: A proof of concept
Date: Wed, 15 Oct 2014 18:06:22 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2

Hello Troye,

Thank you for continuing to work on Savane.

I'd first like to emphasize that major changes to GNU Savannah and/or Savane 
are not going to happen fast.
I'm stressing this point to prevent disappointment or misleading notions - any 
changes to the running code on the production GNU Savannah servers will take a 
lot of time and a lot of reviewing before they are incorporated.
This is not to say that such changes will not happen - on the contrary: GNU 
Savannah does need to be improved, and volunteersare always welcomed.

Please note that there are other attempts going on at rewriting Savane, some of 
them aim at modern PHP.
There's also a more general discussion/debate as to what is the optimal 
platform for Savane/GNU-Savannah - I'm not aware of any definite decisions.
That means that rewriting in Perl is a valid option, but not yet "the chosen" 
approach (if there is even such a choice).

Feedback, suggestions and more discussions are very welcomed, for everyone.

More specifically:

On 10/12/2014 10:24 PM, socketpro wrote:
I have a model for porting Savane ("savane") from PHP to Perl, and I also have a working 
model made of Template input files, .pl, sample DB data for running the .pl script on the 
"savane" database, and httpd.conf files, else this post would not be of much interest.

All files to install can be dowloaded with these links:

Would you be willing to try your improvements on the local-savane-setup:
Either here:
Or here:

And provide an INSTALL file detailing how to set it up locally?

I'm hoping to encourage more people to hack on Savane locally, making 
development easier.

Using the current GIT repository, and supplying patches against it would also 
help others to see how your improvements build upon the existing code - that 
would be easier than using tarballs.

Here are some aspects of the plan:
  o the DB schema currently used by savane can be re-used by "Perl savane"
  o the "backend" will work w/o modification(s)
  o bug trackers, forums, news, mailing lists, "the frontend", etc., will work 
w/ data currently in the DB; schema can be re-used
  o the "frontend" and all pages constructed by the application will still use 
the themes and images under frontend/php/{css,images}, therefore pages generated will 
look the same (using same images and CSS), thus users will not even know they are using a 
Savane written in Perl rather than PHP
  o Template Toolkit ("") will be given data to generate HTML pages 
for clients. Thus, most of the Perl Savane API will just be functions that manage data 
and pass it off to Template to be displayed in some CGI script (or modperlv2)--your 

That's a good plan.

Currently I have lib/Perl/Savane/{,,} modules written. The proof of concept uses 
these three modules. manages "forum data" fetched from the database using, 
and the script calls "print Template->process()" to display the webpage. 
Instructions for this are at the end of this document.

I'm wondering out loud:
If the goal is almost a complete rewrite of the front-end,
Wouldn't it be beneficial to start with one of the well-established Perl 
web-frameworks (e.g. Mojolicious/Catalyst/Dancer) ?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]