[Helma-user] Proposal for future Helma project organization

[Michael Platzer]

Robert Gaggl schrieb:
> First i'd like to state that i really appreciate hannes' proposal, as 
> it's a first important step towards a clearer structure of the helma 
> project itself and the further development. So i'm all +1 for it.
>   
great. i would suggest that we set a target date for the 'bootstrapping 
phase' if no dissenting votes are raised (speak up now, or remain silent 
forever :-) ), in order to get things moving.
> I think it will need careful consideration which parts will be a 
> "module" in the sense of a separately maintained subproject. For the 
> development part of helma at the beginning i can imagine only two of 
> them: helma core and  javascript-lib(s). Both modules will possibly be 
> divided into different modules in the future [1]. But the development is 
> just one part in the project, besides documentation/training, release 
> management and communication/presentation (including website 
> maintenance), which i personally consider of equal importance.
>   
me too. and that's why i would also define them as being a 'module'. 
otherwise we start out with helma committee of two people, which feels 
kind of lame.

or we rethink the requirement of a member to be a module-maintainer, and 
decouple these two things.
plone's membership guidelines for example feel less formal, but are 
probably still effective, since it is based on trust and personal 
judgement instead of predefined rules: 
http://plone.org/foundation/membership/meritguidelines/ (i know that 
being a module-maintainer does not automatically mean being a committee 
member)

i think, we should restate the main goals of the bylaws, respectively of 
the new community structure. ergo, what do we expect from such a 
process? in my opinion, the objectives are the following:
1) relieve pressure from Hannes, by establishing a structure that does 
not necessarily depend on him as a person.
2) a clear definition of responsibilites, in order to know who is 
supposed to do what and when?
3) a clear definition of decision processes, in order to make them more 
transparent, fairer and faster.

we should keep these in mind, when discussing the bylaws.
> Reg. the helmaLib module: Imo it shouldn't start with the mutation of a 
> custom library (be it of orf.at, knallgrau, systemone or any else) into 
> the new "official" helmaLib. There is already a broadly used helmaLib, 
> and development should happen based on it in a way described above. 
> Hopefully a lot of issues addressed in all those custom libs will move 
> into the helmaLib, but in many cases this probably won't happen without 
> modifications. Of course this might mean refactoring work in existing 
> apps, but the benefit one gains with that is one thing less to maintain 
> (that's why i'm sure it will happen).
>
> The helmaLib as i imagine it can't be a replacement for all those custom 
> libraries, but it will hopefully allow them to focus on special needs, 
> so i strongly believe that the helmaLib *must* be a common denominator 
> in the same way helma core is (i'm absolutely sure that this is 
> possible). And i personally have a lot of expectations in it.
>   
The helmaLib right now is a mixture of some javascript-helpers 
(String.js, Date.js,..) and some java-wrappers (helma.File, helma.Ftp, 
helma.Http,..). For the former, I rather prefer a javascript-library, 
such as prototype.js, which is widely known and also used for 
client-side javascripting. For the latter, I prefer using the 
java-libraries and -classes directly, since their APIs are well 
documentated and well tested, and the pool of available, useful 
libraries [1], [2], [3] is just endless.

But the tasks/issues that a web developer daily faces go much much 
further than the helmaLib currently covers. It's about security, form 
validation, model validation, pagination, searching, code testing, code 
documentation, clean mvc separation, ajax integration, upgrade 
mechanism, design patterns, naming conventions, and so on. Building a 
helma framework that goes that far based on a common community 
agreement, which tries to please everybody, just doesnt seem realistic 
too me (considering the lengthy discussions  we have seen here on this 
list from the past).

But maybe/hopefully i am proven wrong. You can be assured, that I will 
try to contribute as much as possible in the future discussions of such 
a library.
In the meantime I will continue (as most of us) writing my own 
framework, and will try to 'release' it for others at some point. Maybe 
its useful, maybe not. (Whereas I was really really glad to read 
Maksim's positive reaction on my mail, which makes me think that the 
former might be the case.)

regards,
  michi


[1] http://jakarta.apache.org/commons/
[2] http://www.codezoo.com/
[3] http://java-source.net/