[ previous ] [ next ] [ threads ]
 
 From:  Marc <telenieko at gmail dot com>
 To:  m0n0wall dash dev at lists dot m0n0 dot ch
 Subject:  Re: [m0n0wall-dev] The future - summary
 Date:  Thu, 13 Oct 2005 23:24:08 +0200
Hi ppl, here are my 2 cents (why do you say: 2 cents? :)

I agree on all that about PHP, me for example, I love m0n0 'cause it's
all PHP and a bit of XML hehe, and wouldn't like see it leaving PHP.
But to be reallystic, it has no multithreading support, all you can do
is play with fork() which in some cases can do the trick (you can take
a look at: http://www.electrictoolbox.com/article/php/process-forking/)
on the other hand, altought maybe we can't get a daemon running there
always and the WebGUI in the other hand I think we should really care
of splitting backend and frontend stuff, so for example, one could say
"I hate the WebGUI, I'll replace it with a nice super XMLRPC
interface" then he/she would only care about the frontend part leaving
backend alone. Then, it is that backend where our troubles are in,
should this backend be a separate daemon? how to comunicate a frontend
with that daemon? well... here's my small idea.

As far as I know m0n0 has a small locking system so if you open
multiple WebGUI sessions there's no trouble... then, why care of
writting a full daemon? you can leaving multithreading to the HTTP
server and make your daemon be "something" that lives on the web
server and acts as a SOAP or XMLRPC listener. For example, you say the
webui "reboot please" then, webui asks to a script on the http server
via xmlrpc "reboot please", that xmlrpc listener should then care
about file lockings and so.

What I'm trying to say is that you don't need to write a full daemon
capable of forking itself, creating and destroying threads, handling
shared memory and so on, you can leave that stuff to a web server
(that anyway, you have to run it for the webui) then you can
concentrate on the real work, which is the backend stuff itself, and
then the frontend stuff.

with that in mind If anyday somebody says "I'm a super freak, I want a
IOS like CLI!" then he/she only needs to read about the
backend<>frontend interface and code his/her CLI (how the cli is
started is something I come now).

Ok, that was the first cent, hope I almost explained a bit well. The
second cent is about 'modularity'. Maybe what you are talking about is
"I have written my super CLI, now how can I make it start and be
nicefull with the others?" there should be something, I repeat
something, like a package system just to say "I'm X, I depend on
modules Y,Z and You have to run A to start me, B to stop me, C to
reload me. My configuration specification is at D" then the backend
itself knows if it can run X (caring about dependencies), also knows
that calling D he'll get configuration specification to bring to the
frontends (remember, we could have more than one frontend, do we want
the frontend coder to write stuff for all modules or leave that for
the backend?) then start, stop, reload as on any stuff that runs on a
box ;)

I think that second cent is not really well explained... hope you understand it!

See you,
Marc Fargas