[Apachetoolbox-devel] Initial

[Kevin J. M. Jr. <km...@WP...>]

Heya fellas,

     Guess I'll write the first email to the list.  And really, there's only two
     people on it, including myself, so perhaps "fellas" isn't appropriate, but
     I'm writing it for the archives ;)

     Bryan set up the mailing list so we can lay out some design goals.  This
     email list is not for general troubleshooting questions or how to use ATB
     or any of its component software.  It's for the further development of ATB.
     If you have trouble with a function you're writing, ask it here.  If you
     have a question about whether or not a module should be included, ask it
     here.  Basically, if it pertains to the development of ATB, ask it here,
     otherwise, go to the forums at www.apachetoolbox.com

     I guess to start, discussion on certain design goals, methods, and other
     implementation details should be ensued.

     With the 2.0 release, ATB is moving from shell scripting to perl.  Perl is
     cross-platform, extensible, and damn cool.  It should relieve all the
     problems that have existed with Solaris and *BSD users in particular.  The
     original thinking was that everyone has a shell, not everyone has perl, and
     that really was good thinking.  But shells are not the same from platform
     to platform, for some God-forsaken reason.  So, the new rationale is, if
     you don't have perl, you shouldn't be running a server anyway ;)
     Seriously, nearly every *NIX system comes stock with a perl distro now, and
     it'd be easier for a user who doesn't, to just get perl, rather than ATB
     try to tailor to that.

     So.  To begin with, I'd like to throw some ideas out there.  Should ATB
     stay procedural, as it pretty much is now, or take an OO approach.
     Ideally, I would think each module could be represented as an object of a
     module class (and in the case of php, sub modules).  It may be harder to
     implement, and Perl OOP gets messy, but the idea is that any new module can
     be defined by just creating a new object.  Certain properties exist in all
     modules (URL to get it from, gunzip/untar'ing it, and so forth).

     Bryan also suggested removing the cache file in preference of an array
     structure (dump the output?).  Perl's text capabilities are awesome, so
     this should not be a problem :)

     I was even thinking maybe a gtk interface at some point, since Perl places
     nicely with that.  But that's really something at the very bottom of my
     list, since I don't run X on any of my servers ;)

     Well, hopefully this list will help out with the progression of the 2.0
     release of ATB.  Probably be best if most, if not all, interaction between
     developers goes through the lists for the sake of archiving.  Likewise,
     please search the archives before asking questions.  Blah blah.

     And any new ideas?  Let's get the planning phase going!

-- 
 Kevin