Darren,
I have felt the missing documentation is a roadblock too, that was the
reason why I put Jira task #59 (Better documentation of our existing
Scala code) on my wishlist for a release.
I've wanted to use ESME to learn Scala/Lift myself, but haven't found
our code being much help at all.
@David: Is this something you could look at?
Not sure how much time you have between now and June 30th?
/Anne
On 18. mai. 2009, at 21.17, Darren Hague wrote:
The outstanding HTML-out-of-Scala-code tickets would be good to
address. I've looked at the Track one, but a couple of hours
investigation led me nowhere. The HTML is just too embedded at the
moment. Unlike the Comet stuff, where the HTML was relatively easy
to extract (because of the nature of Comet), I had no luck with the
other stuff, short of wondering how to initialise a Scala XML node
from an HTML file - for which I couldn't find any example code
anywhere.
Right now, and speaking as someone who's been dabbling in Scala &
Lift for over a year, the ESME codebase is just too hard to work
with in many of the areas I've investigated. Whatever it takes, and
however long it takes, we need to get the codebase into a state
where it is understandable and maintainable, and this is mostly
beyond my skills at present. I will buy the available Lift & Scala
books as available to see if this helps, but in the short term my
effectiveness is limited. I'm happy to do pattern-based work - if
someone can show me an example of how something should be done, and
wants a bunch more of it done, then I am happy to pitch in.
Please note that I am not down on Scala & Lift themselves - I
presented Scala to my team last week, and got some good feedback (to
the degree that I may be allowed to include some Scala in the
production code I'm working on) and I will be presenting Lift in the
next few weeks.
All the best,
Darren
Vassil Dichev wrote:
I've been thinking myself what it would take to release a finished
version. A release would make it easier for others to try out ESME
and
a release schedule would motivate us to focus on short-term goals.
I could add ESME-53 (Access pools), and the associated feature
requests 54-57. Access pools are a personal itch, as their absence
was
the main reason a certain micromessaging solution has been rejected
in
a team I've been in. A lot of the server functionality for access
pools is finished and the work left is mostly related to the UI.
I wasn't fully aware that HTML cleanup from the scala files is
stopping development of the current UI. If that's the case, I should
probably put the access pools on hold and focus on this task, so
others are not blocked by 60-63. Is this the case?
As for a rewrite- anything more significant than the HTML/Scala
refactoring is not at all realistic for a release schedule 1 1/2
months from now. I would prefer that any rewrite with our current
resources is incremental, if possible, otherwise it would mean ESME
development is frozen for months. I have no desire to kill whatever
inertia ESME has without any visible results at this time. It should
be possible to focus on areas, which are not affected so much by the
perceived inelegance of the code base. Remember- for the outside
world
it is important for ESME to deliver, otherwise it's easy to conclude
ESME development is stalled.
Vassil
