Henri Gomez wrote:

The AJP13 protocol will have to be enhanced (or better enabled) to use the
'Service channel' and 'Data Filter'. It is not necessary to define all
Service channel modes like server topology, or server readiness, neither to
define all the Data Filter modes like cryptography or compression. I was
thinking of something like 'extensions' to the protocol, meaning that one
can extend the protocol to some desired level.

Yes.

My initial idea for AJP/1.4 wass to mix on the same wire request forwaring which is the core functionnality of AJP/1.3 with system messaging.

- Service channel is a channel to send/received update between Apache
  and Tomcats :

  - Negociation between Apache and Tomcat.

    * Should we use an authentification scheme between Apache and
          Tomcat (ajp1.3 make that Tomcat trust any Web server
          caming via AJP13).

        * Should we compress the requests/replies

        * Should we crypt the requests/replies.

  - Web Applications state updates :

    * a Web Application is added

    * a Web Application is removed


- Updates in cluster configurations :

    * worker1 was handling 25% of total load, now it could handle
          35%.

    * worker2 in cluster is down for maintenance....

        * Apache 2 could use worker3 for this cluster, it could reach it
          at IP/PORT....


This sound like a lot of features. I'm sure others will be added to the list by other people. That is my concern - it seems the assumption is this will be a very simple module, so there is no need for modularity or a flexible design. On the other side, just like in all other "it's going to be very simple" cases, features will keep piling.

It's one thing to have just apache2 module and ajp13 ( and nothing more), another thing to have all the above.

The real problem is:

1. figuring the list of features.
- I agree multiple protocols ( incl jni) and multiple servers should be droped.
- We seem to agree on having "cluster reconfiguration" feature.
- I'm not sure if we agree or not on dynamic add/remove of webapps.
- It seems I'm alone in wanting monitoring and finer reconfiguration.
- we agree on strong integration with the server
- I'm not sure about about the "add/remove" of webapps versus "strong integration" - I haven't seen any answer on how they can work togheter, it seems Mladen solves this by removing "add remove webapps", which IMO is bad. I just don't know how you can have both at the same time - the only solution I found so far is to have 2 operating modes.



2. design. It seems a lot of people believe this will stay "simple" and there is no need for a flexible design (i.e. components, etc ). If it is a clear understanding that the feature list will be frozen - i.e. if you want more features, you'll need to write a new module from scratch and not reuse anything from this - then it may work, but I never seen this happening in open source.


If C-Mbeans are too complicated - then maybe we can use GObject ( from gnome ) or XPCom components ( from mozilla ) ( or some subset of it). But please, don't start another "simple" project that in a year will have to be rewritten. Object oriented programming does have some value:-)


Costin




--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to