You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Alex Karasulu <ak...@apache.org> on 2007/04/13 13:19:01 UTC
[Shared] shared-ldap is a mess (was: Re: [JNDI] Utility Library)
Hi all,
Just for the record I'm not trying to slam Ole but all of us for the mess
that is shared-ldap: myself included. Ole just triggered this thought.
Let me start by saying shoving code into shared-ldap has to stop. We have
so much crap in there because many of us don't stop and check if the utility
code we're putting in there has not already been implemented. So Ole, and
everyone else please check if what you have written is already there. Learn
what shared-ldap contains and if the junk in there cannot be understood ask
about it. Demand that the mess gets cleaned up.
shared-ldap is huge. It's gotten to be the largest artifact we product I
think at this point. There is vestigial code in there that needs to be
removed as well. I think when we get to a point where we start to re-factor
somethings we should focus on cleaning up this place.
Before taking on nice little refactoring projects in the server we should
focus on cleaning up this place. Why? Because no one wants to clean up
this area since it's not rewarding.
I also don't want to see the rest of the server look like this bad example.
If those who made the mess don't clean it up then the mess spreads to other
places.
Alex
On 4/12/07, Ole Ersoy <ol...@gmail.com> wrote:
>
> Ah - Cool - I'll have a looksee.
>
> I wrote some DIT navigation
> utility methods. Maybe we can shove them
> in there. Hopefully it's new material :-)
>
Re: [Shared] shared-ldap is a mess
Posted by Ole Ersoy <ol...@gmail.com>.
Emmanuel,
I think we are thinking the same thing.
Since this is digital we get to make a brand new room.
We then make a system for storing things in the new room.
Each thing going in the new room has a designated spot.
Then we take things in the old room that are ready
to be placed in the new room, and put it there.
Then we write javadoc according to our defined
quality requirements. The javadoc is the
inventory control system for the new room.
When someone needs something they check the javadoc.
This way the new room is really clean.
This is like taking a messy room, removing everything,
dusting off and cleaning up various things that were in the room,
and then putting everything back in the proper place.
So I'm just using the new room as the final destination for
classes that have been cleaned up. Class that are ready to
go, can just be put there. In this case, the fact that they are in
the new room only symbolizes that they have gone through our quality
control process.
WDYT?
Cheers,
- Ole
Emmanuel Lecharny wrote:
>
>
> On 4/15/07, *Ole Ersoy* <ole.ersoy@gmail.com
> <ma...@gmail.com>> wrote:
>
>
>
> SNIP
>
> > (1) touch only as needed and contain until rewrite
> > (2) refactor gradually as best as we can without big bang or until we
> > realize that a big rewrite is needed later but still try to
> improve it
> > (3) ... any more ideas?
>
> How about this?
>
> We start with fresh Utility Classes.
>
> Each class is centered around a core concern,
> such as:
>
> Navigation
> IO (create, read, update, delete)
> Parsing
>
> Each method that goes in these
> classes has to be well documented (javadoc)
> and tested (All corner cases
> and edge conditions).
>
> We also follow an agreed upon set of conventions
> for defining the Utility packages and Class Names (And Ideally
> class members, but that requires more discussion to find
> conventions that are acceptable to all I think). I also
> need to look at Jakarta commons to see if they have other
> methodology that could be useful.
>
> We then generate Javadoc and put it in a central
> place, so that utility concern classes and methods
> are visible.
>
> When one of us needs a utility, and can't find it in the new shared
> utilities, we ask on the mailing list
>
> If no-one responds,
> the person needing it creates it
> and puts it in an existing utility class,
> or creates a new class corresponding to a new
> concern area.
>
> This allow a clean utility library to grow as needed
> by the team. I think it's essentially option [2].
>
>
> I don't think this is a viabl option. This will just lead to another new
> big mess. We have a lot of good classes in shared-ldap, and we should
> reorganize them. Rewriting everyting is simply crazy. We have some parts
> which are also really bad, and we know which ones, noyt becaus ethe code
> is bad, but because the target was missed. For instance, the Message
> classes are really really bad. We have to rethink the way to mix two
> tragtes into one set of classes for those set of classes (internal
> message manipulation, and codec)
>
> We also need to separate some classes into smaller packages, like
> utility packages, codec package, etc.
>
> But ditching what we have because it's a mess is a kind of NIH syndrom.
> It's like a messy room : you don't throw everything in your room just
> because it's a mess, you clearly clean the room.
>
>
> --
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com <http://www.iktek.com>
Re: [Shared] shared-ldap is a mess
Posted by Emmanuel Lecharny <el...@gmail.com>.
On 4/15/07, Ole Ersoy <ol...@gmail.com> wrote:
>
>
>
> SNIP
>
> > (1) touch only as needed and contain until rewrite
> > (2) refactor gradually as best as we can without big bang or until we
> > realize that a big rewrite is needed later but still try to improve it
> > (3) ... any more ideas?
>
> How about this?
>
> We start with fresh Utility Classes.
>
> Each class is centered around a core concern,
> such as:
>
> Navigation
> IO (create, read, update, delete)
> Parsing
>
> Each method that goes in these
> classes has to be well documented (javadoc)
> and tested (All corner cases
> and edge conditions).
>
> We also follow an agreed upon set of conventions
> for defining the Utility packages and Class Names (And Ideally
> class members, but that requires more discussion to find
> conventions that are acceptable to all I think). I also
> need to look at Jakarta commons to see if they have other
> methodology that could be useful.
>
> We then generate Javadoc and put it in a central
> place, so that utility concern classes and methods
> are visible.
>
> When one of us needs a utility, and can't find it in the new shared
> utilities, we ask on the mailing list
>
> If no-one responds,
> the person needing it creates it
> and puts it in an existing utility class,
> or creates a new class corresponding to a new
> concern area.
>
> This allow a clean utility library to grow as needed
> by the team. I think it's essentially option [2].
I don't think this is a viabl option. This will just lead to another new big
mess. We have a lot of good classes in shared-ldap, and we should reorganize
them. Rewriting everyting is simply crazy. We have some parts which are also
really bad, and we know which ones, noyt becaus ethe code is bad, but
because the target was missed. For instance, the Message classes are really
really bad. We have to rethink the way to mix two tragtes into one set of
classes for those set of classes (internal message manipulation, and codec)
We also need to separate some classes into smaller packages, like utility
packages, codec package, etc.
But ditching what we have because it's a mess is a kind of NIH syndrom. It's
like a messy room : you don't throw everything in your room just because
it's a mess, you clearly clean the room.
--
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: [Shared] shared-ldap is a mess
Posted by Ole Ersoy <ol...@gmail.com>.
SNIP
> (1) touch only as needed and contain until rewrite
> (2) refactor gradually as best as we can without big bang or until we
> realize that a big rewrite is needed later but still try to improve it
> (3) ... any more ideas?
How about this?
We start with fresh Utility Classes.
Each class is centered around a core concern,
such as:
Navigation
IO (create, read, update, delete)
Parsing
Each method that goes in these
classes has to be well documented (javadoc)
and tested (All corner cases
and edge conditions).
We also follow an agreed upon set of conventions
for defining the Utility packages and Class Names (And Ideally
class members, but that requires more discussion to find
conventions that are acceptable to all I think). I also
need to look at Jakarta commons to see if they have other
methodology that could be useful.
We then generate Javadoc and put it in a central
place, so that utility concern classes and methods
are visible.
When one of us needs a utility, and can't find it in the new shared
utilities, we ask on the mailing list
If no-one responds,
the person needing it creates it
and puts it in an existing utility class,
or creates a new class corresponding to a new
concern area.
This allow a clean utility library to grow as needed
by the team. I think it's essentially option [2].
Old utility methods can be replaced gradually. We just
need to map old utility methods to the new ones, so that
we know what to update.
Thoughts?
Cheers,
- Ole
Re: [Shared] shared-ldap is a mess (was: Re: [JNDI] Utility Library)
Posted by Alex Karasulu <ak...@apache.org>.
On 4/13/07, Emmanuel Lecharny <el...@gmail.com> wrote:
>
> Alex is plain right. Shared-ldap is a mess, and I feel culprit about the
> part I have added into it.
Hey we all did our part in this area so don't blame yourself.
At some point, we should realize that fixing such a pile of sh*t is like
> trying to cure cancer with aspirin...
Hahaha. I like that analogy.
However, as we will have to live with it for a little more time (say we can
> have a clean shared-ldap for 1.6), we should avoid as much as possible to
> add some more code, some more classes and some more aspirin ...
Well let's just add if it is not present. Do some diligence to check if the
stuff we are adding has already been put in there. This thing is so big
that it probably has what you need already in it. If not something close is
there which can be better parameterized to handle your use case.
I will suggest that we put a new JIRA (cleaning shared-ldap) and start
> working on it just after ApacheCon EU. We can also drop some thoughts and
> proposal on a wiki page (Refactoring Shared-ldap) in the meanwhile.
Well you're right we're not going to fix it. Perhaps a rewrite with 2.0 is
a good time to start with a clean shared API? For now we should try to keep
the mess ass contained as possible?
Don't know myself just asking.
Many people want to use a clean API to interact with the server, and I must
> say I feel ashamed when I exhibit shared-ldap... Those guys working on
> LdapStudio are suffering every day because of this API.
>
> Let's clean the mess.
Well let's ask ourselves if this is the right time or if we should do some
small refactoring of this stuff.
Options:
(1) touch only as needed and contain until rewrite
(2) refactor gradually as best as we can without big bang or until we
realize that a big rewrite is needed later but still try to improve it
(3) ... any more ideas?
Alex
Re: [Shared] shared-ldap is a mess (was: Re: [JNDI] Utility Library)
Posted by Emmanuel Lecharny <el...@gmail.com>.
Alex is plain right. Shared-ldap is a mess, and I feel culprit about the
part I have added into it.
At some point, we should realize that fixing such a pile of sh*t is like
trying to cure cancer with aspirin...
However, as we will have to live with it for a little more time (say we can
have a clean shared-ldap for 1.6), we should avoid as much as possible to
add some more code, some more classes and some more aspirin ...
I will suggest that we put a new JIRA (cleaning shared-ldap) and start
working on it just after ApacheCon EU. We can also drop some thoughts and
proposal on a wiki page (Refactoring Shared-ldap) in the meanwhile.
Many people want to use a clean API to interact with the server, and I must
say I feel ashamed when I exhibit shared-ldap... Those guys working on
LdapStudio are suffering every day because of this API.
Let's clean the mess.
Emmanuel
On 4/13/07, Alex Karasulu <ak...@apache.org> wrote:
>
> Hi all,
>
> Just for the record I'm not trying to slam Ole but all of us for the mess
> that is shared-ldap: myself included. Ole just triggered this thought.
>
> Let me start by saying shoving code into shared-ldap has to stop. We
> have so much crap in there because many of us don't stop and check if the
> utility code we're putting in there has not already been implemented. So
> Ole, and everyone else please check if what you have written is already
> there. Learn what shared-ldap contains and if the junk in there cannot be
> understood ask about it. Demand that the mess gets cleaned up.
>
> shared-ldap is huge. It's gotten to be the largest artifact we product I
> think at this point. There is vestigial code in there that needs to be
> removed as well. I think when we get to a point where we start to re-factor
> somethings we should focus on cleaning up this place.
>
> Before taking on nice little refactoring projects in the server we should
> focus on cleaning up this place. Why? Because no one wants to clean up
> this area since it's not rewarding.
>
> I also don't want to see the rest of the server look like this bad
> example. If those who made the mess don't clean it up then the mess spreads
> to other places.
>
> Alex
>
> On 4/12/07, Ole Ersoy <ol...@gmail.com> wrote:
> >
> > Ah - Cool - I'll have a looksee.
> >
> > I wrote some DIT navigation
> > utility methods. Maybe we can shove them
> > in there. Hopefully it's new material :-)
> >
>
>
>
>
--
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: [Shared] shared-ldap is a mess (was: Re: [JNDI] Utility Library)
Posted by Ole Ersoy <ol...@gmail.com>.
How about this?
We start with fresh Utility Classes.
Each class is centered around a core concern,
such as:
Navigation
IO (create, read, update, delete)
Parsing
Each method that goes in these
classes has to be well documented (javadoc)
and tested (All corner cases
and edge conditions).
We then generate Javadoc and put it in a central
place, so that utility concern classes and methods
are visible.
When one of us needs a utility we ask on the mailing
list.
If no-one responds,
the person needing it creates it
and puts it an existing utility class,
or creates a new class corresponding to a new
concern area.
Thoughts?
Cheers,
- Ole