As an abbreviation, feels a bit forced, but as a random made-up word Aseca sounds alright. A bit close to Acegi, which could be good or bad and then again, they renamed that project to Spring Security (Acegi 2 anyone? :)
Kalle On Sat, Mar 14, 2009 at 8:30 AM, Les Hazlewood <[email protected]>wrote: > Ok, I think I might have a winner here: > > Application SECurity Api (ASECA) > > Nothing comes up at all in a USPTO search, it is generic, kinda rolls off > the toungue/easy to pronounce, it does not assume an Apache 'blanket' > project, and best, it does not have any existing software projects that I > can find. In fact, there is only one decent match from google for the > "Association of Securities and Exchange Commission Alumni", which I don't > think anyone will disagree is _totally_ different and unrelated to our > project. There are some PDFs that reference 'aseca', but none are related > to software or security. > > What do you guys think? This might be the best I can come up with... > > - Les > > On Fri, Mar 13, 2009 at 9:15 PM, Alan D. Cabrera <[email protected] > >wrote: > > > > > On Mar 13, 2009, at 10:09 AM, Les Hazlewood wrote: > > > > Now that I've had time to think about it more, if ASF and the Incubator > >> are > >> ok with 'Apache Security', I think we should try to use that as the > >> project > >> name. > >> > >> This would certainly open up the floodgates for lots of contributions > from > >> the ASF community and new ideas, given that it would have wider > >> visibility. > >> Many projects (Geronimo, Tomcat, et. al) could all help guide us as to > >> what > >> they would want. I think that'd be great for the project's livelihood, > as > >> well as be nice for the ASF community as a place where they could > >> consolidate and focus efforts. > >> > > > > That's the case for us right now. Interest in this project is based > solely > > on the product itself and the openness of the community, not by the > > implication of the name. > > > > Mentors - do you think we could use that name? (Or Apache Security API > or > >> Apache Security Framework, or whatever)? > >> > > > > There would be HUGE resistance from the other projects that are doing > their > > own security mechanisms. > > > > IMO, let a thousand flowers bloom. > > > > > > Regards, > > Alan > > > > > > > >> > >> On Fri, Mar 13, 2009 at 4:14 AM, Emmanuel Lecharny < > [email protected] > >> >wrote: > >> > >> David Jencks wrote: > >>> > >>> > >>>> On Mar 12, 2009, at 11:50 AM, Les Hazlewood wrote: > >>>> > >>>> Per this thread: > >>>> > >>>>> > >>>>> http://www.jsecurity.org/node/1081#comment-289 > >>>>> > >>>>> It appears that we can't use Ki. > >>>>> > >>>>> So far the development team seems to be happy with "Apache Security > >>>>> API", > >>>>> which can have (good) far reaching implications for a good quality > >>>>> framework. Any objections? > >>>>> > >>>>> > >>>> I think it implies that this project is happy to include all java > >>>> security > >>>> work at apache. For instance, would you be happy to include a xamcl > >>>> jacc > >>>> implementation that did not use your Subject but rather the JAAS > >>>> subject? > >>>> It would certainly be a java security implementation but AFAICT has > >>>> little > >>>> to no overlap with what you are doing now. > >>>> > >>>> I think it also has a connotation that apache has somehow approved > your > >>>> api and all projects needing java security are expected to use it. > >>>> > >>>> Dunno if anyone else gets these ideas from the name but I do. And I'm > >>>> certainly not implying anything about the nature or quality of this > >>>> project.... just that naming one project for the entire field of which > >>>> it is > >>>> an example may not be without problems and implications. > >>>> > >>>> There is some implication that need to be overviewed, that's for > sure. > >>> Now, > >>> we may need a general security umbrella for many different project > >>> related > >>> to security. This could be a good starting point. > >>> > >>> > >>> -- > >>> -- > >>> > >>> cordialement, regards, > >>> Emmanuel Lécharny > >>> www.iktek.com > >>> directory.apache.org > >>> > >>> > >>> > >>> > > >
