Re: [Shared] API Design Questionnaire #1
On Sun, Jan 30, 2011 at 5:11 PM, Alex Karasulu akaras...@apache.org wrote: On Sun, Jan 30, 2011 at 3:17 AM, Emmanuel Lecharny elecha...@gmail.comwrote: 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 Kind Regards, Stefan
Re: [Shared] API Design Questionnaire #1
On Sun, Jan 30, 2011 at 7:29 PM, Stefan Seelmann seelm...@apache.orgwrote: On Sun, Jan 30, 2011 at 5:11 PM, Alex Karasulu akaras...@apache.org wrote: On Sun, Jan 30, 2011 at 3:17 AM, Emmanuel Lecharny elecha...@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. I did not suggest anyone said that. If you read above I am saying I have no choice but to post and share with the community rather than do it myself. -- 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
Re: [Shared] API Design Questionnaire #1
On 1/30/11 7:07 PM, Alex Karasulu wrote: On Sun, Jan 30, 2011 at 7:29 PM, Stefan Seelmannseelm...@apache.orgwrote: On Sun, Jan 30, 2011 at 5:11 PM, Alex Karasuluakaras...@apache.org wrote: On Sun, Jan 30, 2011 at 3:17 AM, Emmanuel Lecharnyelecha...@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. I did not suggest anyone said that. If you read above I am saying I have no choice but to post and share with the community rather than do it myself. We have to be careful in our phrasing. Or we should be careful in the way we understand things. The *I* notation in shared has been added temporarily in order to ease the refactoring, and should be removed in trunk. Again, injecting them in trunk was probably a wrong move, and should have been done in a branch. We all know that... Ok, assuming that this was just a misunderstanding, I guess we can move on. -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
