Mladen Turk wrote: > > Well, what I was yelling about was the core components, like load > balancer, uriMap, uriEnv. > We can write our own functionality, copy the code from the APR, or > something else if faster. These are the components that cannot easily be > supported using #idfef HAS_APR #elif MOZILLA #else... > > So, we need a decision, are we going to use (for example) > apr_time_now(), write our own, using #ifdef #else, or what for those > core components?
As I said, the load balancer, mapper and uriEnv ( and most other components) should be pluggable. You should be able to have multiple balancer implementations and select the one you want. Or have multiple mapper implementations and select one. ( for uriEnv it may be a bit more complicated, as it must 'extend' the base structure - most likely a 'pure virtual' aproach would help in this case ). If this is not possible now - we should fix it first, then add the alternate components ( with no #ifdef ). > Other thing. If we say that core components has to be 'non-mandatory' of > any component like apr or nspr or whatever, the code like #ifdef HAS_APR > must not be in such a component, or it loose its meaning like component > free. And what is component free code (APR doesn't belong to that > category, it is more a system abstraction layer like posix). What I'm saying is that jk2 'core' should consist of jk_env, possibly jk_config and the 'definition/programming model' for components. The current jk_channel_socket, mapper, etc are a set of components - with the caracteristic that they can work in apache1.3 or other cases without APR, that the code is very close to the one in jk1, etc. If we are not modular enough to support alternate implementations for jk_uriEnv - than we should fix this problem first. For channels I'm pretty sure it is possible, and for mapper it should be easy. Also for marshalling it should be easy. > So... > If you wish make some draft about what are the core components, what is > 'mandatory' inside them and what is not, so that we know how to write > the code for such a component. All I'm saying is that most components should be replaceable. What seemed the most important was the channels, protocol and the vm plugin - and for that it seems to work. There is no reason why you couldn't add code to find a component by name - the config is a special case because it requires a bootrsrap ( i.e. it must be hardcoded that you want jk_my_apr_config ), but for all other components it should be easy ( and desirable ) to support multiple implementations. And if we have some strange operating system or piece of code that is not abstracted by APR ( like starting Kaffe VM or accessing some OS-specific feature that is not portable by definition and as such not supported by APR ) - then a specific component can be used. I think jk_env and what's related with the components is 'mandatory', everything else could have multiple implementations. Costin > > >> -----Original Message----- >> From: news [mailto:[EMAIL PROTECTED]] On Behalf Of Costin Manolache >> Sent: Tuesday, October 01, 2002 7:13 PM >> To: [EMAIL PROTECTED] >> Subject: RE: [VOTE] JK2 2.1 >> > > MT. -- Costin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
