Thanks Emmanuel for the status update. I must admit that I'm a bit lost in following all the modifications. But I trust you all that you do the right things. It's good to see progress.
Kind Regards, Stefan On Sun, Jan 23, 2011 at 11:06 AM, Emmanuel Lecharny <[email protected]> wrote: > 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 > >
