Dinesh Nair wrote:
>> One thing that can really stop this problems is m0n0 having a WELL 
>> DEFINED API to integrate modules, like a new feture in menu to upload 
>> modules. I was figuring out about how to do this, and I can say that it 
> 
> 
> m0n0 already does have a basic framework for adding in third party 
> modules, though one would need to be able to generate the CF images for 
> that to work well. if this is insufficient, then by all means start work 
> on getting this up to speed. as you say, this will greatly enhance third 
> party module development for m0n0 and indirectly allow your m0n0patches 
> project to flourish.

Yes I can write a patch to create a new framework for modules, but what 
I  want is the directions to have it commited in the project. This 
should be a very large effort, even larger than the internationalization 
patch, so I'm not interested in maintain it off from the project. I'm 
even thinking in writing a manual for people develop their modules. So 
before start I need to know what are the spectative from the core team 
about doing this.

As I said earlier, I think that the necessity of having the pathes 
generated on images is not a good ideia cause it is not so trivial. 
Instead, the person that want a module should have it without doing 
this. A way to do so is having every modules as a new MFS, that can be 
mounted in /modules directory (just an example), so people developing 
things that need binaries should have them there. The problem is about 
the way of includding this inside the webgui. I don't know deeply the 
minihttpd structure. And about the configuration of the modules , they 
should easly be mantained inside the config.xml, by just using $config, 
and the framework that already exist to save it.

I think using this aproach, the integrity of the main m0n0 should be 
held, even if a modules does not work very well, and the project can 
even detach some functions as modules to have m0n0 a little bit lighter

Jean