Bèr Kessels wrote:
Op donderdag 3 februari 2005 11:51, schreef Carl McDade:
> This paradigm is not condusive to bloat or anarchy in that the true 
core
> [...]
> adjustments and increasing its size with extensions.

The success of the various unices (linux at the top) lies in the fact 
that 
small progams (anloge: modules) do one thing, but do it well. 
Instead of that windows-environment where you need yet another Freeware 
app to 
do yet another task only to find out it does neraly the same as foobar, 
with 
that minor difference. I.e: there is not one single CD burner 
application for 
windows that does its job good and nothing more. you will find loads of 
apps 
that allow you rto rip, collect, and even play music. 
So why should we need:
burner.module
burner-with-ripper.module
burner-withplayer.module
burner-with-oggplayer.module 

when the best solution is to have burner.module, ripper.module, 
player.module 
ogg.module. And to make them work together?


Regards,
 Bèr
  
That solution is fine as long as the core is player.module and burner and ripper and ogg. There would be problems though if someone wanted to extend player module in a manner that does not actually add function but in reality changes player.module to something other than its original capabilities.

ie the original:

    player.module (wmv,mpeg,asf) /burner /ripper /ogg

In the present state of thingswith a closed system core, needing to add Mpeg2 functionality would be:

    player.module (wmv,mpeg,asf) /burner /ripper /ogg -> newplayer.module (mpeg2) /burner /ripper /ogg
    or
    player.module ( /burner /ripper /ogg)  wmv,mpeg,asf -> newplayer.module (mpeg2)

So you can see where the module bloat is coming from. Inorder to use any of the players two modules have to be loaded everytime because of their interdependacy. The module rather than being upgraded by the new functionality becomes interdependant. The solution to this would of course be to redo the core module so that it is open to all formats and does not provide its own core format. this way would set only one  :

player.module ( /burner /ripper /ogg)  -> newplayer.module (wmv,mpeg,asf ,mpeg2)
or
player.module ( /burner /ripper /ogg) 
                                                        -> newplayer.module (wmv,mpeg)
                                                        -> newplayer.module (asf ,mpeg2)

This is of course is a large task and smacks of OOP.  So a good end solution would be to  remove player .module from it's "core" status and set it to "plugin" status this would allow it to  be changed to:

    player.module (wmv,mpeg,asf,mpeg2) /burner /ripper /ogg

Which would reduce the load on the core and give more flexibility to the module. The decision to make the  player.module part of the core was not a good one. The player.module should have been a fully seperate module to begin with. This goes back to my previous statement that "many" of the modules should not be extended but made replacable. This does not apply to every module and there should be a set criteria for "core" and "plugin".

I hope this is confusing enough to understand ;)



--
Untitled Document Carl McDade
Information Technology Consult
www.carlmcdade.com
carlmcdade@gmail.com

Customer Relationship and E-commerce Technology Services for small businesses ____________________________________________________________________________
kläppavägen 9a
82735 Ljusdal
Sweden
tel.0651-15805   telefax 0651-10875

Organisationsnummer: 590310-2050
VAT-nr. SE590310205001
Innehar F-Skattebevis
bankgiro: 5115 4433