in reply to RE: Re: Organization Redux
in thread Organization Redux

Hey, glad to be of help. My thoughts are pretty much entirely centered around making sure your Apache configuration is set2go FIRST before you get fuddy-duddy. What I mean by "permission set mask" is that it might get confusing- which users may have access to which directories, etc. If you don't want (nobody) to read the file, simply set it in Apache- it's much more readable and much more integrable (since you'll be grouping all of your security stuff into one convenient Apache .conf instead of some security measures here, some there...) Your directory structure, as I said, has little to do with "security" per se- all you really need to do is have a meaningful Apache configuration. Every directory can have its own .htaccess file as well as other configuration mechanisms. You can, of course, look more into this at the Apache FAQ. What I see here is too much time spent on something that may be effective but could have been simplified with a few lines in Apache .conf. By default, I believe, .pl is executed as CGI, so you might want to turn that off or consider renaming your itty-bitty perl libs to .lpl or something. You should definitely change your configuration to serve ONLY files that have a specific suffix- this is the base of webservice security. You may at some point want to throw in some documentation for the program, maybe in the form of a .txt or .doc. You certainly don't want that served out. So use LIMITs in the .conf liberally and your security is ALL set. Remember, it's most useful to the future programmers to look at a .conf rather than scrunge through a potentially large number of directories searching for a permission set. Apache.org has numerous examples of configurations, probably one already that fits your needs to the T. Order deny,allow is your friend and that should be seen multiple times in your .conf. It means, if it's not confirmed to be served- don't serve it. (period)

About your library routines: I obviously don't know enough to make an informed decision about your packages and their future usefulness, but I would still find a centrally located directory of packages infinitely more useful. If you are writing packages of non-reusable code, you're missing the point of OOP- REUSABLE CODE! Reusable code is infinitely more useful than a function-specific package. Even if you have to write a few more lines in the main function, you are saving yourself trouble later by making the package reusable by other layers of programming, especially in the debug phase which is the leech on programmers' brains...well, have fun!

AgentM Systems nor Nasca Enterprises nor Bone::Easy nor Macperl is responsible for the comments made by AgentM. Remember, you can build any logical system with NOR.