Ok, That all makes sense. Just had been out of touch from the conversation. I'll put this down as a 2 thang.
-Brian On Tue, 2002-08-27 at 00:12, dann frazier wrote: > On Mon, Aug 26, 2002 at 04:49:04PM -0500, Brian Finley wrote: > > Currently SystemImager has three libraries (or modules) named Client.pm, > > Server.pm, and Common.pm. > > > > It has recently been suggested that we break out into several different > > modules with names based on functionality, as opposed to the machine > > that they run on. > > actually, this had been proposed, discussed on the list & we had code in HEAD > to start the transition at one point. > > >http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/systemimager/systemimager/lib/SystemImager/?only_with_tag=unstable-2_1_x-HEAD-PREMERGE > > > Questions to be answered or discussed: > > * What is the advantage of having several small modules over one > > or two big modules? > > - It makes more sense to associate files w/ their functionality then with. > where they are installed. One example is when a client begins to require > functionality in the server module. Installing the extra file on the client > is a cleaner solution then deleting the code from server module & throwing > it in the client server. > - There's a bug with how the list of flavors is determined. where do i look? > Server.pm? Common.pm? Flavor.pm? > - Scripts can import only the functional components they need > - layers of abstraction are good. as an example, not a well thought out > suggestion, consider this: > Flavor.pm exports functions that tell you about flavors for different > architectures. probably 2 or 3 functions, very short file. > Flavor.pm requires Rsync.pm, which provides all the functions for > parsing rsync output. > an example: > get_boot_flavors($arch, $version, $server) { > my $bootlisting = Rsync::list_module($server, "boot/".$arch); > ...code to parse $bootlisting... > } > > the person reading this code doesn't need to know how rsync works, that's > an irrelevant detail that just clouds this code and makes it more difficult > to read. one day if we, god forbid, switch to something other than rsync, > this code doesn't need to change much. s/Rsync/Srsync/ > - everyone is doing it. > > in summary, modularization is a good idea for more reasons than just code > re-use (which multiple files also lends itself too). maintainability, > readability, expandability, etc, etc. > > > > * What are the disadvantages of having several small modules? > > more inodes? i dunno. > > > * How do other projects do it -- particularly large, complex > > projects? > > take a look at the packages we use in our build system. > busybox, linux, & uclibc are all made up of lots of .c files, each > providing their own function. there isn't a accessing_files_on_a_scsi_disk.c, > instead there are files that handle the scsi layer, files that handle the > filesystem, files that handle the system calls, etc. this separation goes > hand & hand with code abstraction - and makes it very clear how the abstraction > is designed. > > it has gotten simpler lately to add supported filesystems. however, sean's > addition of jfs still had to touch 5 or so files, iirc. > if there was a single jfs.pm file, that exported the right functions & > variables, then adding a new filesystem could be as simple as copying a > skeleton fs file and changing some default values. > > this could work like so: > instead of all the if (fs == "jfs") print "mkjfs.." (or similar, > not looking at the code now). there could be a single fs->mkfs(...) call that > just does the right thing for that filesystem. > > > * How should the modules be categorized? > > http://sourceforge.net/mailarchive/forum.php?thread_id=975189&forum_id=8921 > > > -- > > [EMAIL PROTECTED] > -- --------------------------------------------------- Brian Elliott Finley http://baldguysoftware.com/ phone: 214.280.8188 http://systemimager.org/ --------------------------------------------------- ------------------------------------------------------- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 _______________________________________________ Sisuite-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/sisuite-devel
