Helma project status update

[Hannes Wallnoefer]

I just posted a status update on the Helma weblog that explains
Helma's current maintainance mode status and it's relationship with
Ringo:

http://helma.org/weblog/2010/06/goodbye_helma_hello_ringo/

If anybody does some significant continued development on Helma 1 code
I'll be happy to link that on the Helma blog as well (or provide
people with the privileges to do so themselves). I'm not sure if
Jürg's github fork already qualifies as such. From the description, it
sounds like it's specifically geared towards his yet-to-be-released
CMS, so it may be better to wait.

Hannes

[Daniel Ruthardt]

Hi Hannes,

one thing that isn't clear to me, especially after your latest blog post:
are you actually against or in favour of continued development using the existing community (e.g. helma.org, name, etc.)?
Would you actually prefer continued development to take place in a forked project?

Greets,
Daniel

> --
> You received this message because you are subscribed to the Google Groups "Helma" group.
> To post to this group, send email to he...@googlegroups.com.
> To unsubscribe from this group, send email to helma+un...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/helma?hl=en.
>

[Hannes Wallnoefer]

2010/6/22 Daniel Ruthardt <dan...@dowee.com>:

> Hi Hannes,
>
> one thing that isn't clear to me, especially after your latest blog post:
> are you actually against or in favour of continued development using the existing community (e.g. helma.org, name, etc.)?
> Would you actually prefer continued development to take place in a forked project?

It depends. For efforts that take Helma to new places, forking may be
the better approach - at least initially, until a common direction has
crystallized. But that's really just affects the svn code trunk -
you're welcome to make appropriate use of the Helma wiki and mailing
list for non-mainline projects and features.

Of course you could use svn branches for experimental features, but
given the ease of development that hosted distributed VCS services
such as github or bitbucket provide, i think that might be
counterproductive. If you're serious about working with the helma
codebase, you might want to use a modern DVCS. Your initial fork may
actually become the new helma mainline at some point of time.

Bug fixes and evolutionary features should go to the helma svn of
course. But expect me and other helma stakeholders to have our eyes on
svn trunk, so it's not going to be as fun as working on your own repo.

Hannes

[Jürg Lehni]

After discussing the matter in more depth with Daniel today, here is what we would like to do in the coming days:

- We would like to ask for the creation of a new email account called ne...@helma.org, redirecting email to all people involved in the fork that we propose to be called 'next' ('Helma Next' in the long form and helma-next as the directory / repository name). The redirection could also go to just one email, e.g. he...@scratchdisk.org, that I would then take care of redirecting further.

- A GitHub user account called helma-org is created, using the ne...@helma.org email address.

- Daniel will convert the helma svn trunk to a git repostory, using user mappings that we have yet to fully define. Here the current list. Please fill in the users marked with '?': (SVN user => GitHub user)

hannes => hns
root => hns
henso => hns
czv => ?
kmfdm => ?
lehni => lehni
michi => No Github account so far?
p3k => chl
robert => grob
stefanp => No Github account so far?
tobi => No Github account so far?
zumbrunn => zumbrunn

This repository will be named helma-mirror and pushed to GitHub.

- helma-mirror will be kept up to date by a daily running syncing script on my server.

- As things progress further, a forking repository called helma-next will be created from it.

- All people involved in the project can fork helma-mirror on their own, test things, and submit patches to the helma-next repository.

- helma-next will use GitHub's issue tracking for the handling of issues and tasks related to the fork.

- GitHub Pages and Wikis will be used to host information related to the helma-next project on github.com/helma-org/helma-next

- We will ask Hannes to have the next.helma.org domain point to these GitHub Pages.

But before going ahead we would like to hear opinions and suggestions on all this. Does this all sound reasonable?

Best,

Jürg

[Daniel Ruthardt]

Hi all,

nothing to add to the below, except some updated user mappings ...

> hannes => hns
> root => hns
> henso => hns

> czv => zumbrunn
> kmfdm => ???
> lehni => lehni
> michi => ???
> p3k => p3k
> robert => grob
> stefanp => stefanp
> tobi => p3k
> zumbrunn => zumbrunn

... which we hope are fine. Corrections, confirmations and completion highly appreciated ;-)

Greets,
Daniel

[Hannes Wallnoefer]

Hi Jürg,

I don't see any problems with this plan. I don't know the svn->git
user mapping makes a lot of sense, but that's up to you of course.

I already set up the next@ email address to forward to you and daniel,
will now send a test mail to see if it's working.

Hannes

2010/6/23 Jürg Lehni <li...@scratchdisk.com>:

[p3k]

Hi there

Just posting to let you know I really appreciate your initiative,
Daniel and Jürg.

(I totally missed the recent conversation here.)

Ciao,
tobi

On Jun 23, 7:08 pm, Jürg Lehni <li...@scratchdisk.com> wrote:
> After discussing the matter in more depth with Daniel today, here is what we would like to do in the coming days:
>

> - We would like to ask for the creation of a new email account called n...@helma.org, redirecting email to all people involved in the fork that we propose to be called 'next' ('Helma Next' in the long form and helma-next as the directory / repository name). The redirection could also go to just one email, e.g. he...@scratchdisk.org, that I would then take care of redirecting further.
>
> - A GitHub user account called helma-org is created, using the n...@helma.org email address.

[Jürg Lehni]

Hannes,

That's great to hear. But currently the email forwarding does not seem to work for either of us. Which addresses are you forwarding to?

For me the best would be ju...@scratchdisk.com

Best,

Jürg

[mykes]

I am willing to offer a server and to run a message board (vBulletin
4) and any other server software (like something helma based).

I am unimpressed with the NodeJS/Jack/NG direction that some people
are taking, and something close to Helma 1.x is where the future of
server side JS is.

I've been using Helma 1.x in production environments for a while now,
and it's solid and fast. I'm not a fan of HopObjects, Skins, ORM, and
some other things Helma does, but at least those things don't get in
the way of getting thins done.

I'm currently writing a series of articles for JSMag about Helma 1.x
and server side JS in general, and I would be happy to promote Helma
NEXT.

Regards

[Andreas Bolka]

On Thu Jul 08 17:23:39 +0200 2010, mykes wrote:
> Helma 1.x is where the future of server side JS is.

[..]

> I'm not a fan of HopObjects, Skins, ORM, and some other things Helma
> does

That must be among the most hilarious combination of sentences I've read
in a while: "Helma 1.x is the future, even though I'm not a fan of any
defining feature of Helma 1.x".

I really suggest for you to have a look at RingoJS, which is just like
Helma 1.x (Jetty, Rhino) except for all the features of 1.x you are not
a fan of (ORM/HopObjects, Skins). Even better: there are various options
to choose among for the latter, if some day you happen to stumble across
a need.

--
Regards,
Andreas

[mykes]

Not true at all.

Helma 1.x does great things with Global object, with repositories,
with static directories (and private static), with providing methods
like onCompile(), onStart(), onRequest(), and notfound_action(),
detection of changed files on disk and doing the right thing
(recompile and load), app.data, DB connection pooling, drop jar files
into lib/ext (really easy), mod_jk support (huge for migrating a big
project from PHP to helma a bit at a time), built-in cron, and more.

[Julian Tree]

Mykes,

I have migrated PHP project into Helma. I would recommend keeping the ORM. It saves a lot of time writing INSERT and UPDATE statements. I know there is caching issues, but just put this line in the

HopObject/onRequest.js file

function onRequest(){
app.clearCache();

}

This will disable the caching and have helma grab data from database everytime. Just have that there until you have migrated everything from PHP.

Julian

[mykes]

I appreciate the suggestion.

Unfortunately, this PHP project I'm converting does a lot of outer
join and union queries, as well as conditionally loading items from
multiple tables to create a single object.

[Hannes Wallnoefer]

Note: I rewrote the original posting because it got people into
trouble for deploying Helma applications, which was not my intention.
The new post is here:

http://helma.org/weblog/2010/06/helma_development_update/

I think the new posting does a better job at explaining the current
status and the motivation behind it. Please let me know what you
think.

Hannes

2010/6/22 Hannes Wallnoefer <han...@gmail.com>:

[mykes]

Thank you Hannes!

On Sep 27, 1:46 am, Hannes Wallnoefer <hann...@gmail.com> wrote:
> Note: I rewrote the original posting because it got people into
> trouble for deploying Helma applications, which was not my intention.
> The new post is here:
>
> http://helma.org/weblog/2010/06/helma_development_update/
>
> I think the new posting does a better job at explaining the current
> status and the motivation behind it. Please let me know what you
> think.
>
> Hannes
>

> 2010/6/22 Hannes Wallnoefer <hann...@gmail.com>: