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