Menu
▾
▴
insomnia-httpd-devel
|
From: Dana R. <chr...@ho...> - 2003-05-07 14:45:36
|
<html><div style='background-color:'><DIV> <P>Looking at the Apache api, I'd be worried about using objects to duplicate their struct because there are so many fields. That could become a problem if the server was getting too much traffic since we don't have direct control over object de-allocation and that memory use is a concern. To compensate for that, some of the fields could be compressed if we used integers instead of strings where we can have defined values for different protocols, methods, etc.</P> <P>For the module why just not stick with a class of static methods for now instead of using a more complicated approach.</P> <P>Dana.<BR></P></DIV> <DIV></DIV>>From: Matthew Cooke <MPC...@LI...> <DIV></DIV>>Reply-To: ins...@li... <DIV></DIV>>To: ins...@li... <DIV></DIV>>Subject: Re: [insomnia-httpd-devel] Module System <DIV></DIV>>Date: Wed, 07 May 2003 14:18:44 +0100 <DIV></DIV>> <DIV></DIV>>Might be worth taking a brief look at the apache module api. This <DIV></DIV>>could probably be improved upon as the request is purely a struct in <DIV></DIV>>apache whereas it could contain functionality if it were an object <DIV></DIV>>in java. <DIV></DIV>> <DIV></DIV>>They will have worked out about handlers accepting/denying a request <DIV></DIV>>etc, <DIV></DIV>> <DIV></DIV>>One url I found is this: <DIV></DIV>> <DIV></DIV>>http://httpd.apache.org/docs/misc/API.html#handlers <DIV></DIV>> <DIV></DIV>>Regards, <DIV></DIV>>Matt. <DIV></DIV>> <DIV></DIV>>Alexander Mueller wrote: <DIV></DIV>>>Hello, <DIV></DIV>>> <DIV></DIV>>>I am currently working on a generic system to extend insomnia's <DIV></DIV>>>core by <DIV></DIV>>>external modules. Such modules would include a library to run CGI <DIV></DIV>>>requests <DIV></DIV>>>(currently a core feature), send files gzipped, a cache manager <DIV></DIV>>>(Matthew mentioned <DIV></DIV>>>this) and so on. I would really like to know whether you have any <DIV></DIV>>>particular <DIV></DIV>>>ideas or suggestions for this. <DIV></DIV>>> <DIV></DIV>>>Thanks, <DIV></DIV>>>Alexander <DIV></DIV>>> <DIV></DIV>> <DIV></DIV>> <DIV></DIV>> <DIV></DIV>> <DIV></DIV>>------------------------------------------------------- <DIV></DIV>>Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa <DIV></DIV>>Clara <DIV></DIV>>The only event dedicated to issues related to Linux enterprise <DIV></DIV>>solutions <DIV></DIV>>www.enterpriselinuxforum.com <DIV></DIV>> <DIV></DIV>>_______________________________________________ <DIV></DIV>>insomnia-httpd-devel mailing list <DIV></DIV>>ins...@li... <DIV></DIV>>https://lists.sourceforge.net/lists/listinfo/insomnia-httpd-devel <DIV></DIV></div><br clear=all><hr>Help STOP SPAM with <a href="http://g.msn.com/8HMIENCA/2731??PS=">the new MSN 8 </a> and get 2 months FREE*</html> |
|
From: Alexander M. <al...@gm...> - 2003-05-07 22:38:28
|
> Looking at the Apache api, I'd be worried about using objects to duplicate their struct because there are so many fields. That could become a problem if the server was getting too much traffic > since we don't have direct control over object de-allocation and that memory use is a concern. To compensate for that, some of the fields could be compressed if we used integers instead of strings > where we can have defined values for different protocols, methods, etc. > For the module why just not stick with a class of static methods for now instead of using a more complicated approach. > Dana. Well, I think Matthew meant "object" as a general term not specific to instances (please correct me if I am wrong). Anyway, I agree with you Dana that we should use static methods in this case as we otherwise might run into memory problems if we create instances too fast. What I imagined is a module class which implements an insomnia module interface providing generic communication methods for the core. Upon startup every module is initialised by the core and added to a module manager. So far I do not see any problems, however it gets more tricky handling the actual requests. We do not only have to pay attention to the order in which the module are invoked (eg: a GZIP module has to run as last one) but also that several modules must not process the same output. Alexander |
|
From: Matthew C. <mpc...@li...> - 2003-05-07 23:38:31
|
Sounds good. Let me know when you have the interface worked out and I will have a go with writing a cache module - probably something simple to start with. Also it's clearly not as simple as just having the same request call being passed into each module in turn - as some modules such as gzip or cache would really need to be processing the output of another module like the cgi-processor (unless they intend to resubmit the request to another module internally - which doesn't sound ideal). Regards, Matt. > What I imagined is a module class which implements an insomnia module > interface providing generic communication methods for the core. Upon > startup every module is initialised by the core and added to a module > manager. So far I do not see any problems, however it gets more tricky > handling the actual requests. We do not only have to pay attention to > the order in which the module are invoked (eg: a GZIP module has to > run as last one) but also that several modules must not process the > same output. > > Alexander > > > > ------------------------------------------------------- > Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara > The only event dedicated to issues related to Linux enterprise solutions > www.enterpriselinuxforum.com > > _______________________________________________ > insomnia-httpd-devel mailing list > ins...@li... > https://lists.sourceforge.net/lists/listinfo/insomnia-httpd-devel |
|
From: Alexander M. <al...@gm...> - 2003-05-08 00:26:22
|
> Sounds good. Let me know when you have the interface worked out and I > will have a go with writing a cache module - probably something simple > to start with. So far this is the code for initialising a module. We cannot use static methods for certain reasons but singletons. Class cl=Class.forName(.......); // Check whether specified class was derived from insomnia.Module if (Module.class.isAssignableFrom(cl)==false) .......; ModuleManager.addModule((Module)cl.newInstance()); > Also it's clearly not as simple as just having the same request call > being passed into each module in turn - as some modules such as gzip or > cache would really need to be processing the output of another module > like the cgi-processor Yes, each module shall modify the output stream accordingly to its work (if it has to process the request of course), but things like the order and overall module combination seem to be needed to be solved. > (unless they intend to resubmit the request to > another module internally - which doesn't sound ideal). No of course not, a module shall not directly interact with others. Alexander |
Thanks for helping keep SourceForge clean.
X