On Fri, 24 Feb 2006, David E. Jones wrote:
>
> Adam,
>
> That's great news... especially since there is so much of your code
> in the Entity Engine! BTW, sorry I didn't check with you directly
> earlier (which I did with quite a few of those who had lots of code
> in the project)... I had a conversation with Ean and he expressed
> strong support for this idea, but I really should have checked with
> you personally as well.
OfBiz becoming an Apache project should allow more people to become aware of
the project; this can only be good.
And, as to my code in EE, I've got plans that I want to do to it. But paying
work keeps trumping things. Below are things I've thought about doing at
various times in the past.
* All the different methods for querying data, both in DelegatorInterface
(which may actually be out-of-sync with GenericDelegator) and GenericValue
are a pain in the ass to remember; I'm thinking some kind of
QueryPlanGenerator system.
* The oft-hinted SQL interface; whereby the EE would be able to parse SQL-like
strings, that reference entity names and fields as tables and columns, then
convert that to whatever backend SQL flavor is in use.
* Plugin architecture to allow database drivers to offer extended features.
This would be used so that with certain features EE provides, you wouldn't
need to use a LCD, but some more efficient representation(postgresql has a
SEQUENCE type, for instance, which can be set as a default value for a
column).
* Better entitymodel/seed data upgrade support. All entitymodel data would
have a version. This version would then be tied to various seed-data
(somehow). Then, when a new version is deployed, EE would apply all
seed-data from the current version to new versions.
* Move TransactionUtil to a separate framework, so it could be reused
separately.
* Convert all simple-methods to janino or bsh equivalent; would make debugging
way easier, and could still support dynamic runtime reloading. I've always
wondered why OfBiz had to invent their own language. Having to learn
another pseudo-language, that's extremely verbose, and is not even as
featureful as several other languages, makes implementing anything in it a
pain in the ass(sorry for saying so, but there it is).
* Use ClassLoader delegations to provide security and separation between code
contexts. This plays more with the wiki stuff we've been working on here.
> Did the instructions for the iCLA (directly from you) and the cCLA
> (which I guess Ean or other officer of Brainfood would need to sign)
> that I sent over make sense? The documents have a fax number and
> postal address in them where you can send them so they go directly to
> Apache.
Haven't looked at them yet.
> BTW, this makes you and Brainfood official contributors to any ASF
> project so if you have done this already for other projects you don't
> have to do it again, and even if not: if you get involved in another
> ASF project in the future you won't have to do it again.
That's good. We use other asf projects too(commons-vfs being a big one, I've
got several features/fixes I need to send upstream).
I've got some paperwork for FSF that does this same thing, but haven't sent it
off yet, due to some legal wording(the paperwork is for individuals, and
doesn't handle the case where said individual is working on behalf of some
company).
>
> -David
>
>
> On Feb 24, 2006, at 10:25 AM, Adam Heath wrote:
>
> > I've discussed with Ean(my boss), and he says that any code that I
> > have
> > submitted, in any checkin, patch, or bug, can be relicensed to the
> > ASL.
> >
> >
> > _______________________________________________
> > Dev mailing list
> >
[hidden email]
> >
http://lists.ofbiz.org/mailman/listinfo/dev>
>
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev
Locked
smime.p7s (3K)