QuillMeantTen has asked for the wisdom of the Perl Monks concerning the following question:

Greetings, I have set out to work on a comprehensive security playbook manager for my home network.
I got started by working on OO automata code using Markov chains to look through bind logs for domain name that were clearly generated by an algorithm (a way to stretch my new found muscles before tackling harder problems
such as the client server idea I have for collecting logs all over the network).

I used module-starter to build the module skeleton. I am almost done with that module but I have no idea how I should package it with everything else.

Should I create a new module named something like "Sec::reporting::tools::automata" and put everything in there but then what will I do if I need to create another submodule named "Sec::whatever::somethingelse"?

Should I just move things around, create folders and update the MANIFEST file accordingly? I dont know whether my folder structure should show any kind of hierarchy between more important modules (such as the one that will orchestrate log normalization then reporting) and more specialized ones (such as the one I'm almost done working on).

My goal is to, once I have the infrastructure laid down upload it to CPAN but I would like it to be as organized and easy to use as possible

Thank you for your time, I eagerly await any advice from more advanced members of this community.

Replies are listed 'Best First'.
Re: Module Architecture
by VinsWorldcom (Prior) on Aug 21, 2015 at 13:04 UTC

    I had a similar question about updating an existing module's monolithic code. I wanted to add more functionality, but wanted to break apart the functions into submodules.

    Perl Module API update or new release

    I settled on a new package name Cisco::SNMP since that best described what my module(s) did. All the similar routines (based on Cisco SNMP MIBs) fit under that: Cisco::SNMP::Line, Cisco::SNMP::Entity, etc. This architecture also allows other people to write a Cisco::SNMP::MyModule and it seamlessly "plugs-in" to my Cisco::SNMP top level.

    Why the background? 1) Shameless plug, 2) so I have an example case to reference for, 3) all the stuff I learned from this:

    • Plan.
    • Plan more.
    • Revisit your plan.
    • No matter how much planning you do, things will probably change, so use a flexible architecture.
    • Use a top level CPAN namespace - don't create a new one.

      • In my case, "Cisco" already existed so I put my modules under there. I've also put some modules under the "Net" top level. "Sec" doesn't seem to be a top level, so I'd avoid it.

    • Keep the name short but descriptive.

      • I was worried about releasing Cisco::NewProtocol::Module in the future so originally thought Cisco::Management::SNMP::Line, C::M::S::Memory, etc. would extend nicely to Cisco::Management::NewProto::Mod. But really, who wants to type module names that long (even if it's only twice - once to use and once to construct). And really, who cares if my somewhat related modules aren't all grouped in one nice package - better to keep SNMP together and future new protocol separate in its own (new) module group.

    • Maintaining backward compatibility can sometimes be more trouble than it's worth.

      • I had no idea how many people used my module (probably none), but wanted to be nice to existing programs. My initial plan of extending Cisco::Management was nice, but needed three releases to update the API, produce warnings for old API usage and finally retire the old API and extend the new one. It was easier to just release a final Cisco::Management and say it's deprecated and reference the new Cisco::SNMP suite.

    Hope some of this helps with your CPAN release planning.

[reply]

      This is most helpful indeed, I have recreated my module again and again before managing to create a plan that could be easily expanded on.

      About the top level namespace I thought about using something along the lines of Linux::Net, since security is only used for some offense tools and network for old MSN management code I'm not sure it would be a good idea to use either of those...

[reply]

        I use Perl almost exclusively on Windows, but the code I write can be used cross-platform - as is the intention for most Perl code. Is your module(s) truly only for Linux? Otherwise, I certainly would not include 'linux' in the distribution name.

[reply]
Re: Module Architecture (directory structure)
by Anonymous Monk on Aug 21, 2015 at 08:03 UTC
[reply]
Re: Module Architecture
by QuillMeantTen (Friar) on Aug 21, 2015 at 08:07 UTC

    thank you very much :) I shall read this right away

[reply]

Back to Seekers of Perl Wisdom