I support Elias's option #2 with some concessions to #1.

My strategy in similar situations would actually be to pick the
implementation and then code to its best-supported API.
Here's what I do support:

(a) Pick one and only one Apache-license-compatible ORM/persistence layer
*implementation* that we can distribute and whose use in Roller we will
support.  It must be robust, reasonably efficient, and work over popular SQL
variants without us having to do a lot of our own work.  (Hibernate has all
of these properties except ASF-license compatibility.)

(b) While it is definitely not a priority for me, I'm just fine with architecting for
pluggability in order to help us switch later more easily if we need to.
However, I would only want to support the use of one API and in fact only
one implementation of that API in practice.  If it happens that developers
can plug in something else at whatever level, they would be welcome to, but
they would basically be on their own.  (Patches would be welcome along the
usual lines of course, but we wouldn't necessarily treat issues experienced
only on some alternate implementation as a bug.)

--a.


----- Original Message ----- From: "Elias Torres" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Wednesday, August 16, 2006 5:42 AM
Subject: A forgotten option: iBatis (was Re: New roller persistence
implementation)



I share some of the concerns that Jeff is bringing up in his mail and
remember that long time ago Ted Husted had offered [1] to replace our
Hibernate backend with iBatis or Cayenne. At the time, Dave said no
thank you because Craig was working on JDO, but I hear mixed reviews on
the work:

1. Some think that a pluggable strategy is good
2. Some would like to just pick one and move on
3. Some think is necessary just for license and we should always use
hibernate

We are fine with #1 and #2 not with #3. Therefore, I want to provide
more support for #1 and #2 and suggest that if we have a pluggable
strategy we could work on an iBatis implementation, maybe Ted will help
us. If we choose #2, we would support an iBatis implementation. I think
you get where I'm going. We are using iBatis internally in different
projects and the experience has been good so far.

I would love to hear your opinion on this.

-Elias

Reply via email to