You can subscribe to this list here.
2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(11) |
Sep
(9) |
Oct
|
Nov
|
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2008 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Gonzalo A. <gon...@gm...> - 2008-03-27 13:24:12
|
On Wed, Mar 26, 2008 at 10:42 AM, Steffen Wendzel <cdp...@gm...> wrote: > Hi Gonzalo, > > > > your project is web-server-independent? > > Yes and No. I currently work on a webserver I call cchttpd (c-coders-httpd) > formance web applications in C/C++ (I currently run a web service based on > PHP and its performance sucks and I will have to buy bigger servers in future > if I get more users what is expensive). I also planed a full CMS written in C or > C++ because I really like these languages. > > My plan is to develop something very basic (like it seems you wanted too). This > can be the base for anything bigger (frameworks, CMS, whatever ...). It should > provide something like sessions, PHP's $_GET/$_POST and the like but it should > also work with other webservers (specially lighttpd -- I made some performance > tests and lighttpd was much faster than apache2.2). well, mod_c/EHTML is quite basic, and provides PHP's's $_GET/$_POST and $_FILES. File uploads are handled in a hacky way: they are saved in a local file (not memory), but the file is unlinked as soon as it is opened. Then, the filedescriptor is available for EHTML programmer. This way, if the process dies unexpectedly, the filesystem storage is reclaimed by the kernel. about web server performance (apache vs libhttpd): 1) does lighttpd provide something like pre-fork? (i.e., a process per concurrent request?). 2) Does lighttpd provide something like mod_rewrite? < ... > > > I just wanted a framework to provide some basic access to web server > > resources (read request, send response, check some aspects of the > > request -like http cookies-, session managment, and so on). > > yup, thats what I want (but for other servers too). Sounds nice. Do you find mod_c/EHTML to cover your needs? If that's the case, would you like to adapt mod_c/EHTML to work with lighttpd and/or other web server/s? If you require some changes to mod_c/EHTML, we are open to any suggestion. Regards, -- Gonzalo A. Arana |
From: Gonzalo A. <gon...@gm...> - 2008-03-26 13:19:09
|
Hi Steffen, On Sat, Mar 22, 2008 at 11:37 AM, Steffen Wendzel <cd...@us...> wrote: > > I just took a look at mod_c. I really like the idea of a > made-easy-c-web-development. Because of this I started my > own c-coding specialized httpd project including a C web dev > system. But today I found mod_c what is exactly what I > develop on (but mod_c is specialized for apache). your project is web-server-independent? > Could you explain me why the development of mod_c doesn't go > on? Maybe I am interested in helping on the development > (specially on EHTML). Well, there are some reasons for that: 1) mod_c/EHTML user community is not quite big, I'm affraid. 2) I am an active user of mod_c. 3) I add a feature and fix any bug as soon as they come up. 4) Since user community is not hughe, there are very, very few feature requests. Matej and me had some different ways of approach the issue of developing web applications in C/C++. Matej (correct me if I am wrong) wanted to emulate .NET framework (therefore, EHTML). I just wanted a framework to provide some basic access to web server resources (read request, send response, check some aspects of the request -like http cookies-, session managment, and so on). I also developed an *SQL data access framework as well named ysql (supports query caching), a template engine (closed source, sory :( ), and a C++ object mapping to relational database framework (named omodel). My particular need was to develop a highly scalable CMS. Therefore, my web application had to split web page design from source code. That's why I used only a very very few items of EHTML, and developed a template engine (based on xml). What are your needs for a C/C++ web application framework? Do you have any particular idea on how C/C++ web development should be done? Regards, -- Gonzalo A. Arana |
From: Matej U. <mat...@gm...> - 2006-09-23 14:27:00
|
Hi I've looked into the new session system (as I am now trying to make DSS usable again) and I figured that you decided to make the type of session management a global setting. I wanted the session management type to be available for each directory (not as a global setting). Why did you decide to make it global? A plugable system doesn't make much sense if you can't choose between various plugged session management types. I would rather see that session management type would be provided on a directory level basis. Enjoy, --- Matej |
From: Matej U. <mat...@gm...> - 2006-09-12 18:21:43
|
On Tue, 2006-09-12 at 10:00 -0300, Gonzalo Arana wrote: > Try running cvs update & recompiling. > I had to add "template<>" (I am completely clueless why) at the > beggining of DECLARE_PLUGIN macro lines. > Many thanks for the prompt feedback! Oh, yeah, I have forgotten to tell ya: The correct way of defining static members is like this: The next two lines should be in Plugin.h: template<class C> std::map<std::string,C*> Pluggable<C>::_map; template<class C> C* Pluggable<C>::_selected = NULL; g++ is responsible for anything else. <-- There is no need for additional defines. All above is defined in ANSI C++ (14.5.1.3). |
From: Matej U. <mat...@gm...> - 2006-09-12 18:01:12
|
On Tue, 2006-09-12 at 11:00 -0300, Gonzalo Arana wrote: > damn, perhaps the samples dir could not be automatically built nor > installed, only by manually: > cd samples && make install > > Do you agree? Sure. What about enabling or disabling it at configure time? We may also link to a local instance of libehtml? - so there would be no problem actually building it together with the whole library. I will try and rewrite the configure file. |
From: Gonzalo A. <gon...@gm...> - 2006-09-08 18:59:31
|
Hi, I am about to attack the default session server now. I've noticed that it creates a thread for each connection. Could we use select/poll/epoll/libevent for using a single thread process? Some notes: 1) Creating multiple processes/threads all of them compeeting to obtain the same mutex is no better than processing one request at a time. 2) Using pthreads prevents core dumps in linux (I guess, I'm not sure), which are usefull for debugging. 3) Using threads is heavier than a single process, each thread requires a separate stack & processor state. 4) No shared memory is required, therefore it is easier to code (shared memory can be mapped in different virtual addresses in different processes, so vectors has to be used). How does this sound to you? Regards, -- Gonzalo A. Arana |
From: Gonzalo A. <gon...@gm...> - 2006-09-08 17:40:07
|
Hi, As you may have seen, I've been commiting my latest work. It has been tested (run apache with valgrind) and seems to work just fine (more tests to come during next week). Some major notes: 1) Session managment shifted from mod_c to EHTML. mod_c is linked with EHTML now (due to this 'code shift'). While this may sound weird, it makes faster ondemand loading ehtml applications (since ehtml is already loaded). This will get removed in near future, when EHTML whill be converted to an apache module (cookieless session requires an output filter to be written, and we could get the extra benefit of having session configuration in EHTML only, not in mod_c->EHTML). Session managment is divided in: 1.a) Session ID generation & validation (SessionIDDriver class) 1.b) Session storage (SessionDriver class). 1.b.I) Recoded a little bit the DefaultSessionDriver (written by Matej Urbas), and 1.b.II) wrote the DiskSessionDriver. 1.c) Session variable handling, serialization & marshalling (Session class) Session ID is now a separate class, which provides some encoding methods (urlencoded, hexencoded, base64encoded). 2) Added some convenience classes: Dictionary (map<string,string> child with serialization & marshalling) & MemBuf (for handling memory buffers). 3) Some documentation is still to be written. As usual, any flames/comments/suggestions are more than welcome. Regards, -- Gonzalo A. Arana |
From: Gonzalo A. <gon...@gm...> - 2006-09-05 15:05:53
|
Hi, I've been busy reworking session structure (compiles, but some testing is still needed). As it is now: * session handling is now in EHTML, mod_c is not aware of session handling. * session id are still binary, but handy methods in SessionID class are provided to get it in hexadecimal, urlencoded, and base64encoded. * still need to parse Cookie header value (for cookie based sessions). * still have to test a little bit the default session driver (this only suffered cosmetic changes). * Attached are o Session.h, which includes SessionID, SessionIDDriver (for session ID generation), SessionDriver (for session data storage). o Dictionary.h (basically a map<string,string>) o DefaultSessionDriver.{h,cpp}: this is how default session driver has been reworked. o Plugin.h: as a reference. Session class provide serialize & marshall methods, whose are used by the session drivers to store & retrieve session information. SessionID can be encoded in hex, rfc1728 (urlencoded), or base64. Should have a default for storing in html forms, urls & Cookie http header. I will begin testing this bunch of code. Any sugestions are more than welcome. Regards, -- Gonzalo A. Arana |
From: Gonzalo A. <gon...@gm...> - 2006-09-01 17:00:29
|
Hi, Perhaps we could use a reference counted class for general use in EHTML. We could otherwise limit to apache request memory pool since it will get destroyed upon request termination. Any suggestions or preferences on this subject? -- Gonzalo A. Arana |
From: Gonzalo A. <gon...@gm...> - 2006-09-01 16:39:48
|
Here it is. -- Gonzalo A. Arana |
From: Gonzalo A. <gon...@gm...> - 2006-09-01 16:36:58
|
Hi, If we are going to handle binary data, I guess we need an utility class MemBuff ('memory buffer'). See attached file for an initial implementation. I would like to avoid memcpy on each MemBuf copy constructor call. We are facing now a 'buffer ownership' problem (i.e.: when should the buffer be freed in MemBuff destructor?). We could use reference counting, but that would require to use an underlying object, and all MemBuff simply have a pointer to the true object. Another possibility (a little overhead in memory & CPU) is to use a circular doubly linked lists of MemBuf objects. All MemBuf objects that point to the same buffer, would be in the same 'ring'. When the last element of a ring is destroyed, the buffer is destroyed. Any other ideas? The first requires another class, while the second requires more CPU & memory. So I guess the first is the best. How does this sound to you? Cheers, -- Gonzalo A. Arana |
From: Gonzalo A. <gon...@gm...> - 2006-08-25 16:20:43
|
On 8/25/06, Matej Urbas <mat...@gm...> wrote: > On Fri, 2006-08-25 at 10:07 -0300, Gonzalo Arana wrote: > > > Well, I've seen ASP.NET having a directive that lets the user decide > > > what size of Id one can use. > > > > I find quite difficult to imagine a good session ID generation > > algorithm for abritrary session length. I would rather loose this > > feature but require to have a good sessionID generation. (what I > > demand for a 'good' algorigthm: below). > > Ok, so here is what we can do: > > Id structure (taken from your mail): > |<-- timestamp -->|<-- geostamp -->|<-- variable sized random bytes -->| > 4 bytes 4 bytes 8 >= bytes > > (I like 8 more :-P) > > - timestamp and geostamp will not make the Id unique nice, perhaps we could add process id and a sequential uint32_t. This way we are even closer to be unique. > I have devised a random byte sequence generator in mod_c_dss. I guess it > is secure enough. > > And I guess we'll have to create an Id generation daemon for (guess > what) Id generation :) I agree. Although I would like to make each ethml instance to generate its own unique session id, perhaps the best approach would be to have a server for this matter. Perhaps we can include a disk-based session store (ala php). This would make things easier (avoid writing a daemon). > > > > 2) Session id generation is in session backend, so if we want to use a > > > > different store (say, *sql, dbm, etc) we have to write a session id > > > > generation algorithm for each one of them. > > > > > > Aye. Would be stupid do reimplement the wheel over and over again. > > > > Indeed :( > > So the plan is to redesign the session API? yes, I was thinking in redesign it. Later I'll send a document explaining a possible approach. > We'll have to retain the plug-in system - to be able to load and select > session types dynamically for each directory. I agree. > The API must be well defined (I know mine was pretty ad-hoc) and should > support: > > - persistent connections > - starting a session > - recalling an active session > - ending a session > - storing/retrieving binary data only (takes a load off of driver > developers - a wrapper should be responsible for more user-friendly > storage strategies) > - it should provide some standard info about the current session: when > it was created, how many bytes are stored etc... > - perhaps data caching (BeginTransaction - FlushTransaction) to send > data in one go. > > You name it... That is all of what I was thinking of. > Well, my idea is to keep the session API as simple as possible, but it > should provide enough to create a wrapper on top of it. We will provide > a wrapper for session storage in EHTML and everyone will be happy :-) I keep agreeing. > Well, you should tell me :P > > > > > Well, yeah. They would use the session API to achieve this, no? Wrap > > > around it... EHTML could provide such key-value session storage. To make > > > it easier to use. Let say EHTMLApplication will have a > > > Session.SetValue(key, value) and Session.GetValue(key). I think I have > > > done something in this way already - but I forgot. > > > > I agree, this would imply marshalling/serializing support in Session class. > > That's something I am definetely in favor of. > > Yep, it is a must in EHTML at least. Of course one is not obliged to use > EHTML and could use the session API directly or with other wrappers - > not bound to EHTML. > > But since EHTML is a convenience library, it should also integrate > session storage... Amen. > > > > That's a good idea, but by 'keyed data' I was meaning 'keyed by session id'. > > Isn't this actually what's being done right now? Storing keyed data? Yes, but I would like to split session handling in: 1) session storage, 2) session id generation 3) session data serializing/marshalling. I guess 1 & 2 need plug-in structure, while 3 does not. So the responsability of session store is *only* to store keyed data, not 2) nor 3). > > > > 3) Shifting your current UNIX-socket-based default session handler to > > > > TCP should be quite trivial. I would do that as well. This way, we > > > > can have a single session server among a cluster of apaches. > > > > > > Yes it is trivial, I planned to do it at some later stage, but I never > > > got to it :P > > > > :D I'll do it, relax. > > Nice :-) There is a comment in the default server's source file - it > says: > > // TODO: Add the remote part of the server... > > You should mainly copy everything that is just above this comment and > use normal sockets instead. > > > Things look promising to me ;-) Same to me. Later on I'll submit a document summarizing all of this. Regards, -- Gonzalo A. Arana |
From: Matej U. <mat...@gm...> - 2006-08-25 15:18:21
|
On Fri, 2006-08-25 at 10:07 -0300, Gonzalo Arana wrote: > > Well, I've seen ASP.NET having a directive that lets the user decide > > what size of Id one can use. > > I find quite difficult to imagine a good session ID generation > algorithm for abritrary session length. I would rather loose this > feature but require to have a good sessionID generation. (what I > demand for a 'good' algorigthm: below). Ok, so here is what we can do: Id structure (taken from your mail): |<-- timestamp -->|<-- geostamp -->|<-- variable sized random bytes -->| 4 bytes 4 bytes 8 >= bytes (I like 8 more :-P) - timestamp and geostamp will not make the Id unique I have devised a random byte sequence generator in mod_c_dss. I guess it is secure enough. And I guess we'll have to create an Id generation daemon for (guess what) Id generation :) > > > > 2) Session id generation is in session backend, so if we want to use a > > > different store (say, *sql, dbm, etc) we have to write a session id > > > generation algorithm for each one of them. > > > > Aye. Would be stupid do reimplement the wheel over and over again. > > Indeed :( So the plan is to redesign the session API? We'll have to retain the plug-in system - to be able to load and select session types dynamically for each directory. The API must be well defined (I know mine was pretty ad-hoc) and should support: - persistent connections - starting a session - recalling an active session - ending a session - storing/retrieving binary data only (takes a load off of driver developers - a wrapper should be responsible for more user-friendly storage strategies) - it should provide some standard info about the current session: when it was created, how many bytes are stored etc... - perhaps data caching (BeginTransaction - FlushTransaction) to send data in one go. You name it... Well, my idea is to keep the session API as simple as possible, but it should provide enough to create a wrapper on top of it. We will provide a wrapper for session storage in EHTML and everyone will be happy :-) Well, you should tell me :P > > Well, yeah. They would use the session API to achieve this, no? Wrap > > around it... EHTML could provide such key-value session storage. To make > > it easier to use. Let say EHTMLApplication will have a > > Session.SetValue(key, value) and Session.GetValue(key). I think I have > > done something in this way already - but I forgot. > > I agree, this would imply marshalling/serializing support in Session class. > That's something I am definetely in favor of. Yep, it is a must in EHTML at least. Of course one is not obliged to use EHTML and could use the session API directly or with other wrappers - not bound to EHTML. But since EHTML is a convenience library, it should also integrate session storage... > > That's a good idea, but by 'keyed data' I was meaning 'keyed by session id'. Isn't this actually what's being done right now? Storing keyed data? > > > > 3) Shifting your current UNIX-socket-based default session handler to > > > TCP should be quite trivial. I would do that as well. This way, we > > > can have a single session server among a cluster of apaches. > > > > Yes it is trivial, I planned to do it at some later stage, but I never > > got to it :P > > :D I'll do it, relax. Nice :-) There is a comment in the default server's source file - it says: // TODO: Add the remote part of the server... You should mainly copy everything that is just above this comment and use normal sockets instead. Things look promising to me ;-) Enjoy, --- Matej |
From: Gonzalo A. <gon...@gm...> - 2006-08-25 13:07:24
|
On 8/24/06, Matej Urbas <mat...@gu...> wrote: > On Thu, 2006-08-24 at 15:22 -0300, Gonzalo Arana wrote: > > Hi, > > > > I am writing this directly to you, just because I considered it to be > > more polite in this way. I don't want to sound like a flamer :(. > > Don't worry, people could spit on me, and I would take it easily ;-) I > don't mind people seeing what I've done wrong - makes me want to better > myself. And, please, do yell at me if I've done anything stupid - I'd > rather twist my ankle than produce stupid code (and leave it in my > projects). :-P Well, just for the record, I prefer public rather than private flames to me :P > > I have a couple of notes regarding current session id generation/handling: > > > > 1) SessionID is to be set in apache configuration (via > > EHTMLSessionIdSize). Is this actually necessary? As a matter of > > fact, it is not honored (you can set it to '1', but the default sesion > > server will force this to be between MIN_ID_SIZE -16- AND MAX_ID_SIZE > > -256-). This should be removed, I think. > > Well, I've seen ASP.NET having a directive that lets the user decide > what size of Id one can use. I find quite difficult to imagine a good session ID generation algorithm for abritrary session length. I would rather loose this feature but require to have a good sessionID generation. (what I demand for a 'good' algorigthm: below). > > 2) Session id generation is in session backend, so if we want to use a > > different store (say, *sql, dbm, etc) we have to write a session id > > generation algorithm for each one of them. > > Aye. Would be stupid do reimplement the wheel over and over again. Indeed :( > > These are not actually errors, I would like to change this as: > > > > 1) id generation should be handled by different plugins (a default > > plug-in must be provided) GenerateId should receive: apache request, > > session-server-connection (it is quite easy to provide unique IDs > > based on any unique TCP connection, although we don't want that data > > to be used on all cases). > > Phew, IDs must be totally secure - very hard to guess - hence, the > better the random generating algorithm, the more I'd like it. But to > make it unique, we could (of course!) use your suggested method. I believe that a 'good' session id generation algorigthm requires: 1) should be hard to predict (some randomness). 2) should be unique historically & geographycaly (I've stolen these fancy terms from RADIUS RFCs). 2.a) historically: could include date & time & some other data. 2.b) geographycally: could include a 'hostid', or something unique. > Nice idea (though I think we cannot forget about randomizing it as much > as possible too). Perhaps we could let session id to grow, but not to shrink below a minimum. A rough scheme: Session id could be: date&time (with resolution up to microsecond) + a sequential value (4bytes) + a random value (4 bytes minimum). So, if that gives us (say) 32 bytes (in hex), we could let session id to grow up to 256 bytes (in hex, for instance). This directive could mean extra-entropy bytes. We would need a good random number generator. > > 2) another set of plug-ins could be provided for 'session store', that > > is, session storage; whose only reponsability is to save keyed data > > (sessions). > > Well, yeah. They would use the session API to achieve this, no? Wrap > around it... EHTML could provide such key-value session storage. To make > it easier to use. Let say EHTMLApplication will have a > Session.SetValue(key, value) and Session.GetValue(key). I think I have > done something in this way already - but I forgot. I agree, this would imply marshalling/serializing support in Session class. That's something I am definetely in favor of. That's a good idea, but by 'keyed data' I was meaning 'keyed by session id'. > > 3) Shifting your current UNIX-socket-based default session handler to > > TCP should be quite trivial. I would do that as well. This way, we > > can have a single session server among a cluster of apaches. > > Yes it is trivial, I planned to do it at some later stage, but I never > got to it :P :D I'll do it, relax. > > 4) In the near future, we could have a scheme like the one attached. > > Building replication should be quite straight forward, since the keys > > are known to be unique (some cares still apply anyway). > I haven't had the time to look into this one. Will do it tomorrow. no prob. This is for future development. Regards, -- Gonzalo A. Arana |
From: Matej U. <mat...@gu...> - 2006-08-24 21:00:31
|
On Thu, 2006-08-24 at 15:22 -0300, Gonzalo Arana wrote: > Hi, > > I am writing this directly to you, just because I considered it to be > more polite in this way. I don't want to sound like a flamer :(. Don't worry, people could spit on me, and I would take it easily ;-) I don't mind people seeing what I've done wrong - makes me want to better myself. And, please, do yell at me if I've done anything stupid - I'd rather twist my ankle than produce stupid code (and leave it in my projects). :-P > > I have a couple of notes regarding current session id generation/handling: > > 1) SessionID is to be set in apache configuration (via > EHTMLSessionIdSize). Is this actually necessary? As a matter of > fact, it is not honored (you can set it to '1', but the default sesion > server will force this to be between MIN_ID_SIZE -16- AND MAX_ID_SIZE > -256-). This should be removed, I think. Well, I've seen ASP.NET having a directive that lets the user decide what size of Id one can use. > > 2) Session id generation is in session backend, so if we want to use a > different store (say, *sql, dbm, etc) we have to write a session id > generation algorithm for each one of them. Aye. Would be stupid do reimplement the wheel over and over again. > > These are not actually errors, I would like to change this as: > > 1) id generation should be handled by different plugins (a default > plug-in must be provided) GenerateId should receive: apache request, > session-server-connection (it is quite easy to provide unique IDs > based on any unique TCP connection, although we don't want that data > to be used on all cases). Phew, IDs must be totally secure - very hard to guess - hence, the better the random generating algorithm, the more I'd like it. But to make it unique, we could (of course!) use your suggested method. Nice idea (though I think we cannot forget about randomizing it as much as possible too). > > 2) another set of plug-ins could be provided for 'session store', that > is, session storage; whose only reponsability is to save keyed data > (sessions). Well, yeah. They would use the session API to achieve this, no? Wrap around it... EHTML could provide such key-value session storage. To make it easier to use. Let say EHTMLApplication will have a Session.SetValue(key, value) and Session.GetValue(key). I think I have done something in this way already - but I forgot. > > 3) Shifting your current UNIX-socket-based default session handler to > TCP should be quite trivial. I would do that as well. This way, we > can have a single session server among a cluster of apaches. Yes it is trivial, I planned to do it at some later stage, but I never got to it :P > > 4) In the near future, we could have a scheme like the one attached. > Building replication should be quite straight forward, since the keys > are known to be unique (some cares still apply anyway). I haven't had the time to look into this one. Will do it tomorrow. Bye, --- Matej |
From: Matej U. <mat...@gm...> - 2006-08-24 18:44:18
|
On Thu, 2006-08-24 at 13:44 -0300, Gonzalo Arana wrote: > Hi, > > I've been working on mod_c side (mainly in mod_c.c & lib_cache.cpp), > and I would like to commit attached patch. > > Please, let me know your feelings about this (see at the top of the > patch, there is a summary). Looks nicer! I have gone through the code and you have a go for commit - I haven't had the time to test it yet, so I hope you did ;-) Oh, one more thing: I'm using 4 spaces instead of tabs (and I'm using KDevelop as a development tool - so I can easily adapt). What do you prefer? Simple tabs, 8 spaces, 4 spaces? Just for the sake of consistency, you know :P If you don't want to care about indentation, no probs, is also OK with me ;) Thank you for that code! mod_c is starting to have a coding team here ;-) Bye, --- Matej |
From: Gonzalo A. <gon...@gm...> - 2006-08-24 17:26:59
|
Hi, I've been working on mod_c side (mainly in mod_c.c & lib_cache.cpp), and I would like to commit attached patch. Please, let me know your feelings about this (see at the top of the patch, there is a summary). Regards -- Gonzalo A. Arana |
From: Gonzalo A. <gon...@gm...> - 2006-08-24 17:17:56
|
On 8/24/06, Matej Urbas <mat...@gm...> wrote: > On Thu, 2006-08-24 at 09:57 -0300, Gonzalo Arana wrote: > > I agree about making it optional. I am thinking in something like: > > Cache non LoadEHTML'es files as well, but those are checked on each hit. > > AutoCacheEHTMLFiles directive? > > There is a catch with the upper directive: > > If we decide to use the directive on a per .htaccess basis, we'll have > to make sure that every access to lib_cache is synchronized - regardless > of whether the option is turned off for all directories or not (the > catch is it's hard to know whether the option is turned off for all > directories or not...) Do you see what I'm trying to say? mmm you mean synchronized due to multi-thread access? If it is a per-server variable, I believe there is no need for syncrhonization. Regards, -- Gonzalo A. Arana |
From: Gonzalo A. <gon...@gm...> - 2006-08-24 16:28:02
|
On 8/24/06, Matej Urbas <mat...@gu...> wrote: > On Thu, 2006-08-24 at 12:55 -0300, Gonzalo Arana wrote: > > I've changed my mind on this a little bit. I've wrote this: > > > > 1) EHTMLAllowOnDemand on|off: if set to off, every ehtml must be LoadEHTML'ed. > > 2) EHTMLCacheAutoRefresh on|off: if set to on, cached ehtml entries > > will be autorefreshed if file has changed (mtime & size are checked). > > > > How does this sound to you? > > Oh, the AutoRefresh stuff... Yeah... Well, this will be a more tricky > thing. You see, HTTPD creates child processes to handle web pages in a > secure manner (perhaps there are other reasons to it, but it's not > important). So, every request is processed in those child processes. The > catch is that whenever we Refresh an EHTML library, it would happen only > in that particular child process that received the request (other child > processes' caches would not be refreshed). > > After a selected amount of precessed requests HTTPD simply kills those > child processes and recreates them instantly afterwards (to prevent > memory corruption etc...) - this is also configured in the httpd.conf > file (I have it configured that HTTPD respawns child processes after > every 20.000 requests). > > Anyways, those newly recreated processes would again have the cache as > was created at httpd's startup time! You see, whatever > refreshing/caching there happened at run-time would be nulled when > respawning of processes happens. yes, I am aware of that, same thing happends for mod_rewrite cached lookups for plain_text & dbm maps. > This does not mean that it doesn't make sense to refresh/cache > libraries. I just wanted to tell you what happens in httpd. I think it is a good thing to save dlopen/dlsym work for MaxRequestsPerChild times. Automatically cached entries will save a lot of CPU time if we don't want to force user to LoadEHTML all of his applications. > Well, at least I think this is what happens in httpd :-D I could be > wrong :-P We could both be wrong :D. Cheers, -- Gonzalo A. Arana |
From: Matej U. <mat...@gm...> - 2006-08-24 16:23:21
|
On Thu, 2006-08-24 at 12:55 -0300, Gonzalo Arana wrote: > I've changed my mind on this a little bit. I've wrote this: > > 1) EHTMLAllowOnDemand on|off: if set to off, every ehtml must be LoadEHTML'ed. > 2) EHTMLCacheAutoRefresh on|off: if set to on, cached ehtml entries > will be autorefreshed if file has changed (mtime & size are checked). > > How does this sound to you? Oh, the AutoRefresh stuff... Yeah... Well, this will be a more tricky thing. You see, HTTPD creates child processes to handle web pages in a secure manner (perhaps there are other reasons to it, but it's not important). So, every request is processed in those child processes. The catch is that whenever we Refresh an EHTML library, it would happen only in that particular child process that received the request (other child processes' caches would not be refreshed). After a selected amount of precessed requests HTTPD simply kills those child processes and recreates them instantly afterwards (to prevent memory corruption etc...) - this is also configured in the httpd.conf file (I have it configured that HTTPD respawns child processes after every 20.000 requests). Anyways, those newly recreated processes would again have the cache as was created at httpd's startup time! You see, whatever refreshing/caching there happened at run-time would be nulled when respawning of processes happens. This does not mean that it doesn't make sense to refresh/cache libraries. I just wanted to tell you what happens in httpd. Well, at least I think this is what happens in httpd :-D I could be wrong :-P Enjoy |
From: Matej U. <mat...@gm...> - 2006-08-24 15:54:09
|
On Thu, 2006-08-24 at 09:57 -0300, Gonzalo Arana wrote: > I agree about making it optional. I am thinking in something like: > Cache non LoadEHTML'es files as well, but those are checked on each hit. AutoCacheEHTMLFiles directive? There is a catch with the upper directive: If we decide to use the directive on a per .htaccess basis, we'll have to make sure that every access to lib_cache is synchronized - regardless of whether the option is turned off for all directories or not (the catch is it's hard to know whether the option is turned off for all directories or not...) Do you see what I'm trying to say? But if we make the upper directive global, we could know for sure that no libs will be added at any time - hence, we could use the current way of handling with the cache. In any event, you are right with synchronization: if we decide to put EHTML files into the cache at 'runtime', we'll have to add some functions (or modify existent - although I prefer the former) which would work with the lib_cache in a thread-safe manner. > > Security comes to my mind in order to tell me NOT to process ehtml > requests that are not LoadEHTML'ed (not sure why yet). Perhaps we > could disable (via an apache directive) on-demand dlopen/dlsym. AllowLoadedEHTMLsOnly directive? Sure, this is a very important feature. EHTML is dangerous and perhaps some people would not trust everyone to add their EHTML applications onto their web servers... What about a DontExecuteEHTML directive (on a per .htaccess basis)? It could prevent execution of EHTML in selected directories. > WIth current scheme, you are right. I was not aware that I was > thinking in caching all requests (my mind works in misterious ways > :D). If we cache ehtml dlopen/dlsym on demand, this should be a > per-server cache. Well, there will be as many copies of the cache as there are child processes created by HTTPD. There is no problem with creating one at configuration-time - it will get copied by the OS when child processes are hooked. (I guess :P) > If we cache per-request, we do have to worry :(. Sory to bring this > up again :(. Yeah, sure you're right. That's what > > Perhaps shall we shift this design threads to mod-c-dev mailing list? I have mailed a copy of this mail to the users list (I think we won't have a lot of users anyways, so we can use the users list for stuff like that). I prefer to have as little mailing lists to worry about as possible ;-) I will mail the users list from now on. Enjoy, --- Matej |
From: Gonzalo A. <gon...@gm...> - 2006-08-23 14:21:25
|
I've noticed that we've been overwriting each other configure script (among other bootstraped files), and they seem to have conflicts quite often. May I add these bootstrapped files to .cvsignore? Regards, -- Gonzalo A. Arana |