Elias Torres wrote:
On 1/30/07, Dave <[EMAIL PROTECTED]> wrote:
On 1/29/07, Elias Torres <[EMAIL PROTECTED]> wrote:
> I know I have been away for over a month now but I still wanted to let
> you know what we have been up to at IBM in regards to the Roller
> project. First, we have some great news around the use of Roller at
> IBM. Lotus announced Connections, a social networking package for the
> enterprise that includes Roller as its blogging component.
>
> Now that the product code is stabilizing, we want to share with you
> the things that we have done and added and plan how we can give these
> back to the project.
>
> - New backend implementation using iBatis
> - Reduction of # of sql queries to increase performance
> - Better cluster support:
> - MBeans implementation to support better administration in a
> clustered environment
> - Completely reworked search to work in clustered environment
> and avoid re-indexing on improper shutdown
> - Tweaked caching strategy to avoid blowin up the heap with output
content
> - Refactored code to have proper HTTP support for Reverse Proxies
> - Cleaned up unnecessary creation of sessions
> - Support for authenticated comments
> - A lot of tweaks to support container managed security and SSO
environments
> - For example, MetaWeblog API relied on passwords stored in the db
> regardless of the setup
Wow. Lots of changes and lots of good things. Thank you and IBM very
much for offering to contribute this to the Roller community. I hope
we can figure out how to get some or all of this work into Roller.
Cool.
I don't want to come off as negative, but I do have a couple of concerns.
Since this work was done in a separate repository by folks who are not
all Roller committers (correct me if I'm wrong), I assume you'll need
to do code grant paperwork to contribute it to Roller.
That's correct.
And since work was done isolation without the benefit of open
discussion on the Roller mailing lists, we probably need to work up
proposals on each of those features/changes so we can have those
discussions now.
Fair enough.
And I don't want to get all preachy, but I would greatly prefer to see
all Roller discussions happen on the mailing list and development
happen in SVN. If developers are toiling away in isolation, we'll
never get to know them, they won't get nominated as committers and the
community won't grow as much as it could. IBM will have fewer votes
too, hmm... maybe I should not be telling you this ;-)
Too late, now we know. :-) I'll take this discussion back to IBM and
ask the developers to start having those discussions in the mailing
list.
I also agree with Dave that having discussions on the list is the best
place, not only so that the developers can be properly recognized but
also so that we make sure that work isn't being done that will
ultimately not be able to go back into the project.
I understand why you had discussions off list and in truth I don't think
that all discussions need to be on the list, but after hearing the big
list of work that you guys did my biggest fear would be that some of
that work can't be contributed because it was implemented in a different
way than the community wants. Hopefully that is not the case here, but
having those discussions on the list helps prevent situations like that.
> I guess the main discussion point I would like to start from this
> email is which data access strategy we should use in Roller. We have
> an iBatis (Apache License) implementation that is working well and
> continually being optimized. So far the results are very promising and
> would like to donate that back. I just want to know if using iBatis
> can still be a choice in the decision and what would need to do to
> make sure it happens.
Oh boy.
I don't think it is too late to discuss iBatis and it's fair to ask
that iBatis be considered as our new persistence framework. We could
get the new iBatis implementation into the Roller 4.0 branch and do a
bake-off of JPA vs. iBatis to see how folks like the programming model
and how performance compares. We could then vote to decide what to do.
Let's do it. :-)
I'll let you guys organize that for the most part, but what this does
bring up is something that I am interested in having for Roller, which
is some automated performance tests.
We do performance testing against the application as a whole, but I
would really like to get a standardized tool for running some automated
performance tests put into the repository so that from release to
release there is a solid way of measuring the performance of any part of
the system. I think the best place to start with this would be to setup
tests against the backend for checking query performance which could be
used in this bake off.
Anyone have any tools that they have used and like for doing automated
performance testing of code?
JPA does have several advantages over iBatis from my point of view.
First, it's a Java standard API with multiple implementations
supported Oracle, BEA, Sun, etc. Second, there is a Hibernate
implementation of JPA, so folks can conceivably continue to use
Hibernate if they want to. And third, for my work I have to support a
JPA back-end. So if the Roller team picks iBatis, I'll be forced to
maintain a second back-end -- not something I want to do.
Oh boy. So on your end, it must be JPA?
As much as I hate the idea, if different members of the community
really want/need different back-end implementations, then I think we
have figure out how to enable that or not. We come back to Craig's
question, how to we let them co-exist. I think there are at least
these issues:
1) Multiple back-end with equal standing. Developers must commit
changes and get tests passing in both back-ends before committing.
2) Multiple back-ends but only one is primary. One back-end is
designated the primary back-end and developers must ensure only that
test pass in that primary back-end before committing.
3) One back-end allowed in SVN. Only one back-end is allowed in trunk
and anybody who
wants some other backend will have to maintain it separately.
I'm certain that our intentions are not to make the Roller development
by maintaining multiple back-end implementations, but we want to know
what really makes JPA the best choice. So far the
multiple-implementations story doesn't convince me. All we need is one
that works with the different dbs and it's easy to use. The simpler
the better.
I won't say that I have any strong opinions about either JPA or iBatis
having not worked with either of them, but I do believe that Dave's
point about JPA being an actual approved Java api is a noticeable
benefit in my mind.
However, regardless of what backend is preferred, the one thing that I
am still very much against is having multiple backends. There is no way
that I want to have to do double work and against 2 different apis in
order to change anything to the Roller backend. And code maintenance
aside, the additional complexity that would present to users is just
silly, there is no need for it and personally I am not even willing to
consider it. So, no matter what apis people prefer for the backend, at
the end of the day I would only be willing to officially support one.
So I am supporting option #3 above.
-- Allen
-Elias
