Return-Path: Delivered-To: apmail-jakarta-taglibs-dev-archive@apache.org Received: (qmail 98815 invoked from network); 30 Sep 2002 13:43:26 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 30 Sep 2002 13:43:26 -0000 Received: (qmail 19752 invoked by uid 97); 30 Sep 2002 13:44:07 -0000 Delivered-To: qmlist-jakarta-archive-taglibs-dev@jakarta.apache.org Received: (qmail 19662 invoked by uid 97); 30 Sep 2002 13:44:06 -0000 Mailing-List: contact taglibs-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Tag Libraries Developers List" Reply-To: "Tag Libraries Developers List" Delivered-To: mailing list taglibs-dev@jakarta.apache.org Received: (qmail 19640 invoked by uid 98); 30 Sep 2002 13:44:05 -0000 X-Antivirus: nagoya (v4218 created Aug 14 2002) Message-ID: <3D985609.1010509@latte.harvard.edu> Date: Mon, 30 Sep 2002 09:47:53 -0400 From: "Mark R. Diggory" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; rv:1.2a) Gecko/20020910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tag Libraries Developers List Subject: Re: Accepting new projects [was: LDAP taglib proposal] References: <3D6DD3C9.5090200@sun.com> <3D6E98E1.78D8E306@sun.com> <3D7D35A7.DBECCFA9@sun.com> <3D943A15.2090102@sun.com> <3D947AC2.6020308@latte.harvard.edu> <3D949062.7090501@sun.com> <3D949B8D.8010802@latte.harvard.edu> <3D94A86D.6EB97BE0@sun.com> <3D94C1EC.968FB8B5@sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Pierre Delisle wrote: >--- >Call for Action > >Here are some things we need to do to help us move forward: > >- All: Is this the right direction? > > We still need to refine the proposal made above, but how > does it sound in general? Is that the direction we should take to > be more flexible in handling new project submissions? > [the main difference with the current rules is that we would not > mandate a project to be fully cooked before being accepted; > we would simply require it to have clear motivation for its importance, > clear commitment from the submitters, and clear interest from the community). > I think the sandbox is important place for projects to start out because otherwise they endup like the current JNDI Taglib, stale and without developers. I think it should be a requirement that a taglib gets a certain following (both in terms of # users and developer support) before it can graduate from the sandbox. With this in mind, having a number of individuals interested in getting together to work on a project in the sandbox should be grounds enough to get a branch started. But,... there should be a definite passage through your development process before files start showing up. We need to isolate that we all want to see the same results from the project. (ie right now some want a LDAP library while others want a JNDI library, while similar in architecture, they encompass different scopes of application). Making sure that the design fits cleanly at both scopes is important. >- JNDI/LDAP > > Orhan, Mark, Mike: Would this process work for all of you interested in a newly > designed JNDI/LDAP taglib? If yes, then I'd propose that you guys decide among > yourself how to get the motivation/comparative analysis documents ready for > consideration by the list. > ------------------ Orhans response > Hi Pierre, > I agree with Glenn in some points. However, your proposal is > acceptable for us. Here is my plan; > - Me, Ayhan Alkan and Murat Go"rgu"ner are going to contribute to > JNDI/LDAP taglib design and development. We'll be glad if Mike and > Mark join us. This would be our team for the project. > - We can prepare motivation, comparative analysis and high-level > taglib design in 2-3 weeks. > > I'm looking for your comments. > Regards > Orhan Alkan I have a couple of questions: 1.) As we all have interest in the design of the library as well as its development, shouldn't this process be exposed to the community (jakarata-taglib's) as well via jakarta-taglib developers list? 2.) As you've somewhat decided that a broader scope JNDI taglib is favored over a narrower scope LDAP taglib, what are we going to gain from a comparitive aalysis? 3.) As a JNDI taglib is basically wrapping the behavior of an already *well* designed package, shouldn't design of the taglib mirror that package? The strategy I had used originally in my project involved creating simple wrapper tags that simply called these methods in the javax.naming,Context/directory.DirContext stored in a scope of the servlet engine. i.e. org.apache.jakarta.taglib.naming.ContextTag org.apache.jakarta.taglib.naming.method.CreateSubContextTag org.apache.jakarta.taglib.naming.method.DestroySubContextTag org.apache.jakarta.taglib.naming.method.LookupTag org.apache.jakarta.taglib.naming.method.BindTag org.apache.jakarta.taglib.naming.method.UnbindTag org.apache.jakarta.taglib.naming.method.ListTag ... org.apache.jakarta.taglib.naming.directory.DirContextTag extends org.apache.jakarta.taglib.naming.ContextTag org.apache.jakarta.taglib.naming.directory.method.GetAttributes org.apache.jakarta.taglib.naming.directory.method.ModifyAttributes org.apache.jakarta.taglib.naming.directory.method.Search ... org.apache.jakarta.taglib.ldap.LdapContextTag extends org.apache.jakarta.taglib.naming.directory.DirContextTag org.apache.jakarta.taglib.ldap.method.ExtendedOperation org.apache.jakarta.taglib.ldap.method.GetRequestControls ... I know the details of what will be implemented out of these would need to be worked out, but the basic concept is that would instantiate/use a jndi context. and that the method tags in directory and naming could act on that context as well (casted into one of its ancestors.). .... .... -My 2 Cents, Mark -- To unsubscribe, e-mail: For additional commands, e-mail: