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.

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.

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.

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 ;-)


> 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.

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.

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.

Other points of view?

I don't see the problem with multiple backends if there's developers
on the team that are willing to support them.  We have 3 backends in
AppFuse (hibernate, jpa and ibatis) and we have developers to support
them.  It seems to work pretty well and we even have a way to easily
allow the end user to switch to the one they want to use.

Is now a good time to bring up how Maven 2 solves many of these module
problems? ;-)

I've learned a *ton* about Maven 2 working with the Ant -> Maven 2
conversion on AppFuse. I'd be happy to do the conversion for Roller if
there's interest.  The biggest reason I can think of for changing is
to make web development easier.

Matt


- Dave



--
http://raibledesigns.com

Reply via email to