what about scanner/handler? :P just my 2 cents, alles gute Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/
On Fri, Jul 29, 2011 at 10:20 AM, Mark Struberg <strub...@yahoo.de> wrote: > Hi James! > > Feel free to suggest a better name. > For the client we also could use 'consumer' but not sure how to name the > piece which does the actual scanning. Ideas? > > txs and LieGrue, > strub > > --- On Thu, 7/28/11, James Carman <jcar...@carmanconsulting.com> wrote: > >> From: James Carman <jcar...@carmanconsulting.com> >> Subject: Re: [sandbox] [classscan] classscan API design review needed >> To: "Commons Developers List" <dev@commons.apache.org> >> Date: Thursday, July 28, 2011, 11:01 PM >> Why the client / server >> nomenclature? Makes it sound too heavyweight >> On Jul 28, 2011 4:20 PM, "Mark Struberg" <strub...@yahoo.de> >> wrote: >> > Hi Simo! >> > >> > Sorry, I guess I was not clear enough! >> > >> > Some specs require us to pickup this info from some >> config (e.g. >> META-INF/beans.xml). The classscan-client needs to pickup >> this configuration >> from there and must tell it the classscan-server somehow. >> This could be some >> form of Domain Specific Language, but I'm not sure if this >> isn't a complete >> overkill here. >> > >> > It could be interesting to use the DSL approach for >> the callback filters >> of course. >> > >> > LieGrue, >> > strub >> > >> > --- On Thu, 7/28/11, Simone Tripodi <simonetrip...@apache.org> >> wrote: >> > >> >> From: Simone Tripodi <simonetrip...@apache.org> >> >> Subject: Re: [sandbox] [classscan] classscan API >> design review needed >> >> To: "Commons Developers List" <dev@commons.apache.org> >> >> Date: Thursday, July 28, 2011, 6:44 PM >> >> Hallo Mark, >> >> >> >> > >> >> > Some classscan-clients maybe first need to >> read some >> >> config files for getting exclude/include info. >> >> > >> >> >> >> sorry for being repetitive but that's here too >> that I >> >> suggest adopting >> >> the Meiyo's alike way of configuring the component >> via EDSL >> >> instead of >> >> config files - there's no reason to adopt an >> approach that >> >> reminds old >> >> J2EE/Spring configurations - unless we aim be >> integrated >> >> ;) >> >> >> >> I had the same problem with moinmoin but honestly >> I don't >> >> remember how >> >> I figured out :/ >> >> >> >> Buona serata! ;) >> >> Simo >> >> >> >> >> --------------------------------------------------------------------- >> >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> >> >> >> > >> > >> --------------------------------------------------------------------- >> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> > For additional commands, e-mail: dev-h...@commons.apache.org >> > >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
