Hi guys,
as you noticed, some heavy code refactoring is going on in shared. Let
me give you some feedback about what is being done, and the reasons for
those refactoring.
First of all, the idea is to release a shared/LdapAPI 1.0-M1 asap. It
will be LdapAPI from this point, and not anymore shared. This will be a
milestone, but it will also be a first step toward the exposed API. When
we will come with a 1.0-RC1, the API will have to be frozen. That being
said, let's see where we are going to :
- base class renaming. You can see that Alex changed DN to Dn, etc. The
rational behind those renamings is that it's consistent with the name
scheme we use : caml humps all over the code. We have a DnParser class,
and a DN class, which is not consistent. All in all, we discussed those
names back in september, and if you really feel that DN is better than
Dn, we can revert, but I thik it's not really a technical issue, much
more a choice to make. To me, it's not an issue at all.
- API/SPI separation : most of what Alex is doing right now is about
hiding implementation from the exposed API. The less classes exposed,
the less problem we might have with users using the SPI classes. ALso
consider that the API documentation will be more tight.
- OSGi : shared has been completely OSGified, and it's a good thing. We
have postponed this task year after year, but we reached a point it was
to be done. One of the reason was that refactoring shared without
impacting Studio was impossible, because Eclipse dos not allow a project
to 'see' shared as a dependent source project, so we had to propagate
the changes manually, something we don't want to do anymore. With the
OSGi bundles, studio is now directly impacted by shared refactoring
without any need to do it by hand. Plus OSGi is the best way to manage
dependencies, and for shared, it cost almost nothing to switch to OSGi
(well, it took one day). I also do think that after shared refactoring,
we have to go for Apacheds.
At the end of the day, the refactoring should be finished soon (maybe
one or two more days). It may create new sub-modules, which may be
gathered later, not a big deal. Just keep an eye at what is being done,
if you disagree, feel free to express your opinion.
One important point is that we are using a c-t-r mode (commit then
review) and not a r-t-c, and I think we don't want to switch to a r-t-c
at this point of the project :). Committing is not for ever, you can -1
one commit, it's not an insult to the one who did the commit. I repeat,
-1 a commit is not an insult. Just be rational, and express your
technical vision when you -1 something.
All in all, at first I was quite conservative, but I realized that we
probably need some fresh perspective, because we are all so deeply
involved that we don't have anymore a 10K feet vision necessary to see
what's wrong and what's good. It's a good timing now that the API is
stable to review it, shake it and make it better.
Guys, I engage you to look at what Alex is doing when it will be done,
and express your opinion then. I think this is one unique opportunity to
move away from a local minimum to the next stable state.
Thanks !
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
