Assistance appreciated: comments.apache.org

2012-07-12 Thread Daniel Gruno
Hello everyone,

I've been put in charge of building http://comments.apache.org, a new
commenting system that projects can use for adding comments to any page
they want to. If you haven't heard about this yet, or need an
introduction to it before reading on, please take a look at
https://comments.apache.org/help.html

So far, so good, it's up and running, but a second set of eyes wouldn't
hurt, so I'm asking if there's anyone interested in either reviewing the
code or just helping out managing the site.

Some information about the system:
It's built in Lua ( http://www.lua.org ) and runs via an Apache HTTPd
module called mod_pLua ( https://sourceforge.net/p/modplua/wiki/Home/ )
which integrates Lua with the HTTPd server's functions. It currently
runs on Lua 5.1, but should it be necessary, we'll upgrade to either
LuaJIT 2 or Lua 5.2 - the scripts are compatible with all versions. The
database backend is MySQL (currently using MyISAM for the comments db),
managed via HTTPd's mod_dbd. Current internal response times indicate
that we can handle a lot of projects (up to 50 million page visits per
day), but as the number of comments go up, this figure will very likely
drop as 90% of what's going on is pure database interaction, and some
optimizations on the database will have to be made. Any suggestions
towards this would be greatly appreciated, as I don't know a whole lot
about database optimizations apart from moar RAM!. The current
configuration is whatever is default for a freshly built MySQL server on
FreeBSD (i.e. I don't know).

The source code for this project is available at
https://svn.apache.org/repos/infra/infrastructure/trunk/projects/comments/
and probably requires some introductory knowledge of mod_pLua if you're
going to review it, but it's written in a very simple way, so even
people with php, perl, python etc skills should be able to understand
what's going on. For those with Lua knowledge, the added
functions/tables in mod_pLua can be found at
https://sourceforge.net/p/modplua/wiki/New%20functions%20in%20pLua/
(except for the string.md5 function which isn't documented yet)

If you want to help out managing the site, you can reply here or on IRC
or wherever infra allows, and we'll see if we can hash out something.
Note that since this is an infra-managed project, it's completely up to
infra to decide who gets to manage the site, not me :). Managing the
site will mean administrative access to the control panel, which will
include duties such as checking logs for irregularities, setting up
sites for people who don't know how, enabling/disabling features (or
shutting down a comment site), promoting/demoting/deleting users and so on.

If you're interested in reviewing the code, the following scripts could
use a checkup:

- common.lua: The general, all-purpose function library and initializer
for all scripts

- add_comments.lua: The script for adding new comments to the db

- moderate.lua: The script for on-the-fly moderation of comments (this
is the one activated when you moderate a comment on the sites that have
comments enabled)

- panel.lua: The control panel of the site. This script is perhaps a bit
cluttered, and some cleaning up would be nice.

- portal.lua: Manages logins for regular users as well as user
registration and email validation. It has a few known kinks that,
although they pose no threat at all, will need to be ironed out in time
for the sake of neatness.

- show_comments.lua: This is the script that sends the array of comments
available to the JavaScript library, builder.js, which displays comments
on the page. It makes (sort of) use of a caching function in
comments_cache.lua, which is currently disabled since it's silly, but
should at some point be made to work. Any suggestions on how to properly
cache comments without ending up with new comments not showing for 10-20
seconds would be greatly appreciated.

So, that's about it for now. Lastly, if you're more interested in
actually _using_ this system for your project, don't hesitate to either
send an email to infra or file a JIRA ticket and you'll get set up as
soon as possible.

With regards,
Daniel.

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org



Re: JSPWiki status (Was: [Incubator Wiki] Update of July2012 by JuanPabloSantos)

2012-07-12 Thread sebb
On 11 July 2012 22:26, Juan Pablo Santos Rodríguez
juanpablo.san...@gmail.com wrote:
 Oh, my misunderstanding then. If that's the case, then there is one
 technicality of the apache release process blocking the release
 (distributing dependencies alongside source), although not a tough one.
 I'll file a Jira and reflect it at the project incubation status page.


 regards,
 juan pablo

 On Wed, Jul 11, 2012 at 1:31 PM, Jukka Zitting jukka.zitt...@gmail.comwrote:

 Hi,

 On Tue, Jul 10, 2012 at 11:03 PM, Juan Pablo Santos Rodríguez
 juanpablo.san...@gmail.com wrote:
  Regarding the binary dependencies. Wasn't the discussion on general@more
  focused on (or raised because of) transitive dependencies which were
  brought into the build and not being AL-compatible?

 No, all the dependencies discussed were compliant with Apache
 policies. The problem was about having binaries included in the source
 archive.

  Also, the build is Ant based, so we need them to be there in order to be
  able to build.

Not so; Apache JMeter and Tomcat both use Ant and have external
dependencies which are not held in SVN.


 The proposed solution for this case was to put the dependencies in a
 separate -deps archive, that can be combined with the source release
 to make it buildable. The build script can also automatically download
 such separate binary dependencies.

That's what JMeter and Tomcat do: there's a separate Ant task to do
the downloads.
But you could also use Ant+Ivy.


 BR,

 Jukka Zitting

 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org



-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org



Re: JSPWiki status (Was: [Incubator Wiki] Update of July2012 by JuanPabloSantos)

2012-07-12 Thread Dave Fisher

On Jul 12, 2012, at 10:38 AM, sebb wrote:

 On 11 July 2012 22:26, Juan Pablo Santos Rodríguez
 juanpablo.san...@gmail.com wrote:
 Oh, my misunderstanding then. If that's the case, then there is one
 technicality of the apache release process blocking the release
 (distributing dependencies alongside source), although not a tough one.
 I'll file a Jira and reflect it at the project incubation status page.
 
 
 regards,
 juan pablo
 
 On Wed, Jul 11, 2012 at 1:31 PM, Jukka Zitting 
 jukka.zitt...@gmail.comwrote:
 
 Hi,
 
 On Tue, Jul 10, 2012 at 11:03 PM, Juan Pablo Santos Rodríguez
 juanpablo.san...@gmail.com wrote:
 Regarding the binary dependencies. Wasn't the discussion on general@more
 focused on (or raised because of) transitive dependencies which were
 brought into the build and not being AL-compatible?
 
 No, all the dependencies discussed were compliant with Apache
 policies. The problem was about having binaries included in the source
 archive.
 
 Also, the build is Ant based, so we need them to be there in order to be
 able to build.
 
 Not so; Apache JMeter and Tomcat both use Ant and have external
 dependencies which are not held in SVN.
 
 
 The proposed solution for this case was to put the dependencies in a
 separate -deps archive, that can be combined with the source release
 to make it buildable. The build script can also automatically download
 such separate binary dependencies.
 
 That's what JMeter and Tomcat do: there's a separate Ant task to do
 the downloads.
 But you could also use Ant+Ivy.

Apache POI uses ant as well. Here are selected parts of the build.xml:

!-- the repository to download jars from --
property name=repository.m2 value=http://repo1.maven.org/
property name=main.lib location=lib/

!-- jars in the /lib directory, see the fetch-jars target--
property name=main.commons-logging.jar 
location=${main.lib}/commons-logging-1.1.jar/
property name=main.commons-logging.url
  
value=${repository.m2}/maven2/commons-logging/commons-logging/1.1/commons-logging-1.1.jar/
property name=main.commons-codec.jar 
location=${main.lib}/commons-codec-1.5.jar/
property name=main.commons-codec.url
  
value=${repository.m2}/maven2/commons-codec/commons-codec/1.5/commons-codec-1.5.jar/
property name=main.log4j.jar location=${main.lib}/log4j-1.2.13.jar/
property name=main.log4j.url 
value=${repository.m2}/maven2/log4j/log4j/1.2.13/log4j-1.2.13.jar/
property name=main.junit.jar location=${main.lib}/junit-3.8.1.jar/
property name=main.junit.url 
value=${repository.m2}/maven2/junit/junit/3.8.1/junit-3.8.1.jar/
property name=main.ant.jar location=${main.lib}/ant-1.8.2.jar/
property name=main.ant.url 
value=${repository.m2}/maven2/org/apache/ant/ant/1.8.2/ant-1.8.2.jar/

target name=check-jars
condition property=jars.present
or
and
available file=${main.commons-logging.jar}/
available file=${main.commons-codec.jar}/
available file=${main.log4j.jar}/
available file=${main.junit.jar}/
available file=${main.ant.jar}/
/and
isset property=disconnected/
/or
/condition
/target

target name=fetch-jars depends=check-jars unless=jars.present
description=Fetches needed JAR files from the Internet
mkdir dir=${main.lib}/
antcall target=downloadfile
param name=sourcefile value=${main.commons-logging.url}/
param name=destfile value=${main.commons-logging.jar}/
/antcall
antcall target=downloadfile
param name=sourcefile value=${main.commons-codec.url}/
param name=destfile value=${main.commons-codec.jar}/
/antcall
antcall target=downloadfile
param name=sourcefile value=${main.log4j.url}/
param name=destfile value=${main.log4j.jar}/
/antcall
antcall target=downloadfile
param name=sourcefile value=${main.junit.url}/
param name=destfile value=${main.junit.jar}/
/antcall
antcall target=downloadfile
param name=sourcefile value=${main.ant.url}/
param name=destfile value=${main.ant.jar}/
/antcall
/target

HTH,
Dave


 
 
 BR,
 
 Jukka Zitting
 
 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org
 
 
 
 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org
 


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: 

Re: JSPWiki status (Was: [Incubator Wiki] Update of July2012 by JuanPabloSantos)

2012-07-12 Thread Juan Pablo Santos Rodríguez
Hi Dave,

thanks for the tip :-) Actually we're downloading a few LGPL jars via
maven-ant-tasks,
but this approach seems simpler for our libs, as we won't have to deal with
transitive
dependencies.


br,
juan pablo

On Thu, Jul 12, 2012 at 9:51 PM, Dave Fisher dave2w...@comcast.net wrote:


 On Jul 12, 2012, at 10:38 AM, sebb wrote:

  On 11 July 2012 22:26, Juan Pablo Santos Rodríguez
  juanpablo.san...@gmail.com wrote:
  Oh, my misunderstanding then. If that's the case, then there is one
  technicality of the apache release process blocking the release
  (distributing dependencies alongside source), although not a tough one.
  I'll file a Jira and reflect it at the project incubation status page.
 
 
  regards,
  juan pablo
 
  On Wed, Jul 11, 2012 at 1:31 PM, Jukka Zitting jukka.zitt...@gmail.com
 wrote:
 
  Hi,
 
  On Tue, Jul 10, 2012 at 11:03 PM, Juan Pablo Santos Rodríguez
  juanpablo.san...@gmail.com wrote:
  Regarding the binary dependencies. Wasn't the discussion on
 general@more
  focused on (or raised because of) transitive dependencies which were
  brought into the build and not being AL-compatible?
 
  No, all the dependencies discussed were compliant with Apache
  policies. The problem was about having binaries included in the source
  archive.
 
  Also, the build is Ant based, so we need them to be there in order to
 be
  able to build.
 
  Not so; Apache JMeter and Tomcat both use Ant and have external
  dependencies which are not held in SVN.
 
 
  The proposed solution for this case was to put the dependencies in a
  separate -deps archive, that can be combined with the source release
  to make it buildable. The build script can also automatically download
  such separate binary dependencies.
 
  That's what JMeter and Tomcat do: there's a separate Ant task to do
  the downloads.
  But you could also use Ant+Ivy.

 Apache POI uses ant as well. Here are selected parts of the build.xml:

 !-- the repository to download jars from --
 property name=repository.m2 value=http://repo1.maven.org/
 property name=main.lib location=lib/

 !-- jars in the /lib directory, see the fetch-jars target--
 property name=main.commons-logging.jar
 location=${main.lib}/commons-logging-1.1.jar/
 property name=main.commons-logging.url

 value=${repository.m2}/maven2/commons-logging/commons-logging/1.1/commons-logging-1.1.jar/
 property name=main.commons-codec.jar
 location=${main.lib}/commons-codec-1.5.jar/
 property name=main.commons-codec.url

 value=${repository.m2}/maven2/commons-codec/commons-codec/1.5/commons-codec-1.5.jar/
 property name=main.log4j.jar
 location=${main.lib}/log4j-1.2.13.jar/
 property name=main.log4j.url
 value=${repository.m2}/maven2/log4j/log4j/1.2.13/log4j-1.2.13.jar/
 property name=main.junit.jar
 location=${main.lib}/junit-3.8.1.jar/
 property name=main.junit.url
 value=${repository.m2}/maven2/junit/junit/3.8.1/junit-3.8.1.jar/
 property name=main.ant.jar location=${main.lib}/ant-1.8.2.jar/
 property name=main.ant.url
 value=${repository.m2}/maven2/org/apache/ant/ant/1.8.2/ant-1.8.2.jar/

 target name=check-jars
 condition property=jars.present
 or
 and
 available file=${main.commons-logging.jar}/
 available file=${main.commons-codec.jar}/
 available file=${main.log4j.jar}/
 available file=${main.junit.jar}/
 available file=${main.ant.jar}/
 /and
 isset property=disconnected/
 /or
 /condition
 /target

 target name=fetch-jars depends=check-jars unless=jars.present
 description=Fetches needed JAR files from the Internet
 mkdir dir=${main.lib}/
 antcall target=downloadfile
 param name=sourcefile value=${main.commons-logging.url}/
 param name=destfile value=${main.commons-logging.jar}/
 /antcall
 antcall target=downloadfile
 param name=sourcefile value=${main.commons-codec.url}/
 param name=destfile value=${main.commons-codec.jar}/
 /antcall
 antcall target=downloadfile
 param name=sourcefile value=${main.log4j.url}/
 param name=destfile value=${main.log4j.jar}/
 /antcall
 antcall target=downloadfile
 param name=sourcefile value=${main.junit.url}/
 param name=destfile value=${main.junit.jar}/
 /antcall
 antcall target=downloadfile
 param name=sourcefile value=${main.ant.url}/
 param name=destfile value=${main.ant.jar}/
 /antcall
 /target

 HTH,
 Dave


 
 
  BR,
 
  Jukka Zitting
 
  -
  To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
  For additional commands, e-mail: general-h...@incubator.apache.org
 
 
 
  

Re: [VOTE] Retire AWF from incubation

2012-07-12 Thread Alan D. Cabrera
+1 binding


Regards,
Alan

 
On Jul 4, 2012, at 2:18 PM, Roger Schildmeijer wrote:

 Hi,
 
 The AWF community has voted to retire the project. 
 Following the retirement guide [1], I now call the Incubator PMC to vote on 
 confirming this decision. (Will be open for 72 hours).
 
   [ ] +1 Retire the AWF project
   [ ] -1 Do not retire the project, because ...
 
 [1] http://incubator.apache.org/guides/retirement.html
 
 WBR 
 Roger
 


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org