directory-api mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <akaras...@apache.org>
Subject Re: [Shared] API Design Questionnaire #1
Date Sun, 30 Jan 2011 18:01:47 GMT
On Sun, Jan 30, 2011 at 7:29 PM, Stefan Seelmann <seelmann@apache.org>wrote:

> On Sun, Jan 30, 2011 at 5:11 PM, Alex Karasulu <akarasulu@apache.org>
> wrote:
> > On Sun, Jan 30, 2011 at 3:17 AM, Emmanuel Lecharny <elecharny@gmail.com
> >wrote:
> >
> >> On 1/29/11 10:38 PM, Stefan Seelmann wrote:
> >>
> >>>
> >>>  [X] - (c)
> >>>>            interface                                 = AddRequest
> >>>>            simple API exposed implementation         =
> AddRequest*Impl*
> >>>>            not so simple internal use implementation =
> >>>> AddRequest*Decoder*
> >>>> We're applying option 'C' right now. I'm torn but think A might suite
> us
> >>>> better for the long term, and for any situation. You also know what's
> an
> >>>> interface and what's not although the IDE automatically shows you this
> >>>> stuff
> >>>> on the package/class browser.
> >>>>
> >>> This is my opinion for a low-level API, which 1:1 maps LDAP
> >>> terminology to the Java API. I think we should additional have a
> >>> simplified API where the user don't need to deal with request and
> >>> response objects at all.
> >>>
> >>> BTW: We have this discussion again and again ;-) We really need to
> >>> decide a consistent naming.
> >>>
> >>
> >> I think we already discussed it more than once, and we all agreed on
> this
> >> convention.
> >>
> >> I'm not sure we want to rehash this again every 2 years :/
> >>
> >>
> > When there's a push to release a 1.0 of an API, we need to make the API
> > consistent. I can do this myself but the community way is to have a
> > discussion. If  you do not want to discuss this feel free not to
> > participate, or say you don't care.
>
> I don't see that anyone said that the API development should not be
> community driven.
>
> In shared and apacheds we currently us a mix of the *Impl* suffix and
> the *Default/<whatever>* prefix for classes. I only count two
> interfaces with the *I* prefix, that is probably caused because they
> were moved from studio to shared. In studio there are many more *I*
> prefixed interfaces, which was inspired by the Eclipse naming
> conventions. But afaik we never used *I* prefix in shared or apacheds.
>
> Oh, I just searched for *I* prefixed files, and now there are 14 more, why
> that?
>
> $ find shared -name "I[A-Z]*.java" | cut -d "/" -f 9-
> shared/dsmlv2/IAction.java
> shared/dsmlv2/IGrammar.java
> shared/ldap/codec/controls/ppolicy/IPasswordPolicyRequest.java
> shared/ldap/codec/controls/ppolicy/IPasswordPolicyResponse.java
> shared/ldap/codec/controls/replication/syncDoneValue/ISyncDoneValue.java
> shared/ldap/codec/controls/replication/syncInfoValue/ISyncInfoValue.java
> shared/ldap/codec/controls/replication/syncmodifydn/ISyncModifyDn.java
>
> shared/ldap/codec/controls/replication/syncRequestValue/ISyncRequestValue.java
> shared/ldap/codec/controls/replication/syncStateValue/ISyncStateValue.java
> shared/ldap/codec/ICodecControl.java
> shared/ldap/codec/IControlFactory.java
> shared/ldap/codec/IDecorator.java
> shared/ldap/codec/IExtendedOpFactory.java
> shared/ldap/codec/ILdapCodecService.java
> shared/ldap/codec/ITestCodecControl.java
> shared/ldap/codec/ITestControl.java
>
>
Yep that's a test. I wanted to see how ugly it would be to get a feel for
it. Then I was going to revert it to which ever scheme we chose.

I don't think I like the I* approach.

-- 
Alex Karasulu
My Blog :: http://www.jroller.com/akarasulu/
Apache Directory Server :: http://directory.apache.org
Apache MINA :: http://mina.apache.org
To set up a meeting with me: http://tungle.me/AlexKarasulu

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message