[Helma-user] Announcement: Jala 1.0

[Michael Platzer]

Wow!

Jala seems to be (yet another) impressive work/contribution from your, 
resp the orf-side. The provided functionality makes a tidy, uncluttered 
impression. Congratulations for getting this out! But above all, the 
excellent documentation of the library is really a great benchmark for 
all of us.

A very quick feedback, mixed with some first question:

 *  jala.AsyncRequest: The need for exactly such a functionality came up 
couple of weeks ago. And we solved this issue quite similar to your 
implementation, by making internal helma-calls in separate threads. We 
might consider switching to this class.

 * jala.History: What is the purpose of this class? I assume that this 
should help, to send the user automagically back to the correct page 
after performing some multi-step-workflow, correct? How do you know 
which one was the last 'non-workflow-page'?

  * jala.I18n: Very interesting to see a different i18n-implementation 
in helma. Making heavy use of the java MessageFormat-class and using the 
wide-spread PO files is a smart move. So, the english text is used as an 
identifier for a message. What happens if one decides to slightly change 
that english message? Do I automatically lose the other translations?

 * java.ImageFilter: Image-Manipulation is a task that we 'outsourced' 
to ImageMagick, as this is the most powerful tool available for such 
tasks. Similar to ImageMagick we also use external libraries for 
transcoding Videos and Audios.

 * jala.IndexManager: This use case was also exactly the same motivation 
for us to implement a AsyncRequest-like functionality, like you did. 
Maybe we will also switch to your implementation.

 * jala.ListRender: Yepp, definitely sthg that is heavily needed in 
every helma developer's life.

 * jala.Mp3Info: The link [http://www.ueberdosis.de/java/id3.html] to 
the ID3Reader-package seems to be broken here 
[https://opensvn.csie.org/traccgi/jala/wiki/JalaModules]. We use the 
MP3SPI-library [http://www.javazoom.net/mp3spi/mp3spi.html] directly for 
similar purposes.

 * jala.PodcastWriter, jala.Rss20Writer: We use the Atom library 
[https://rome.dev.java.net/] directly for similar purposes.

 * jala.RemoteContent: This class mimics a 'forward proxy cache', 
correct? We also implemented a similar, but less generic functionality 
for fetching feeds. If such a functionality is used heavily, one might 
consider implementing a limitation for the size of the cache directoy. 
Anyways, also this class is of great interest for us.
> Of course, there's even more on the way, eg. a module for handling forms
> and submitted data as well as a unit testing environment for Helma
> applications. Stay tuned for further releases!
>   
> To obtain information about getting and using Jala please point your
> browser to the Jala project site at
> https://opensvn.csie.org/traccgi/jala/.
>   
One minor tipp regarding the documentation: If you commit the 
documentation, that is currently contained in the wiki-pages [e.g. 
https://opensvn.csie.org/traccgi/jala/wiki/JalaModules], into the 
repository itself, then you will get automated versioning/branching also 
for the documentation. And Trac allows one to automatically render files 
with a specific suffix (e.g. '.wiki') in the SVN Browser as regular wiki 
pages.

Regarding Installation: I would suggest developers to integrate jala (or 
any other third-party-library that has a svn repository) via 
svn:externals [http://svnbook.red-bean.com/en/1.0/ch07s03.html]. That 
way, you don't need to install (download) Jala separately from your 
application, and you can handle version dependencies between your 
application and the libraries directly in the SVN-repository of the app.

I just wish I could use the 'helmaLib', resp. 'helma' the same way. Any 
new decisions or opinions on whether we switch to a trac/svn setup (also 
for helma 1.x)? I put up a demo-installation for a migrated cvs 
repository at https://trac.knallgrau.at/tmp-helma
> We hope you find Jala as classy and useful as we do. And please take
> this announcement as a kind invitation to participate in Jala's further
> development.
>   
As I said, the first look of Jala is very promising. Some of the 
provided functionality is definitely highly interesting for us. In what 
form do you want to receive feedback in the future? Should we use this 
mailing-list, a separate mailing-list or Trac's ticketing system?

Again: Congratulations! And Thanks!

  michi