Re: IIS Connector for TC4.0

2001-09-17 Thread jean-frederic clere

GOMEZ Henri wrote:
 
 I feel we'll need some schemas on mod_jk workers
 and webapp broker to see how to better understand
 them :)

And an updated WARP Protocol documentation ;-)

 
 -
 Henri Gomez ___[_]
 EMAIL : [EMAIL PROTECTED](. .)
 PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
 PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
 
 -Original Message-
 From: Pier Fumagalli [mailto:[EMAIL PROTECTED]]
 Sent: Friday, September 14, 2001 8:10 PM
 To: [EMAIL PROTECTED]
 Subject: Re: IIS Connector for TC4.0
 
 
 GOMEZ Henri [EMAIL PROTECTED] wrote:
 
  1) Release TC 3.3/4.0
 
 DOH! :)
 
  2) Start to think on how to merge AJP14/WARP
 
 Let me know when
 
  3) Add the AJP14-WARP protocol to mod_jk and mod_webapp (adaptation)
 
 I'll keep track of the protocol modifications in TC4 and WebApp
 
  4) Add APR to mod_jk and worker concept to mod_webapp
 
 Well, the worker seems to be an hybridization of
 wa_connection+wa_provider.
 Basically a big object-like structore holding configuration
 (wa_connection) and code (wa_provider)...
 
 Pier
 
 



RE: IIS Connector for TC4.0

2001-09-14 Thread GOMEZ Henri

So, IMO, it's a win-win situation... JK can support all 
web-servers and all
old protocols, it's tested, it works, we just need to make 
it able to talk
the new AJPv14/WARP protocol and can be used as the strong 
foundation.
WebApp will talk only AJPv14/WARP, based on APR, and only 
ported to Apache
1.3 and 2.0, when we're happy with it, with the 3.3 implementation of
AJPv14/WARP, with the new/revised/corrected APR-based API, 
we can start
porting all other stuff over, and in 12 years time we can 
deprecate the old
one...

Does it make any sense?

Yes -

Pier which will became my best friend :)



Re: IIS Connector for TC4.0

2001-09-14 Thread Pier Fumagalli

GOMEZ Henri [EMAIL PROTECTED] wrote:

 So, IMO, it's a win-win situation... JK can support all
 web-servers and all
 old protocols, it's tested, it works, we just need to make
 it able to talk
 the new AJPv14/WARP protocol and can be used as the strong
 foundation.
 WebApp will talk only AJPv14/WARP, based on APR, and only
 ported to Apache
 1.3 and 2.0, when we're happy with it, with the 3.3 implementation of
 AJPv14/WARP, with the new/revised/corrected APR-based API,
 we can start
 porting all other stuff over, and in 12 years time we can
 deprecate the old
 one...
 
 Does it make any sense?
 
 Yes -

Maybe to you, but buddy Costin doesn't like it... :)

 Pier which will became my best friend :)

Hope so... I'm _trying_ to be nice :)

Pier




Re: IIS Connector for TC4.0

2001-09-14 Thread jean-frederic clere

GOMEZ Henri wrote:
 
  WebApp will talk only AJPv14/WARP, based on APR, and only
  ported to Apache
  1.3 and 2.0, when we're happy with it, with the 3.3
 implementation of
  AJPv14/WARP, with the new/revised/corrected APR-based API,
  we can start
  porting all other stuff over, and in 12 years time we can
  deprecate the old
  one...
 
  Does it make any sense?
 
  Yes -
 
 Maybe to you, but buddy Costin doesn't like it... :)
 
 No I'm sure Costin like the merge, and I like
 you all comment the following timing :
 
 1) Release TC 3.3/4.0
 
 2) Start to think on how to merge AJP14/WARP
 
 3) Add the AJP14-WARP protocol to mod_jk and mod_webapp (adaptation)
 
 4) Add APR to mod_jk and worker concept to mod_webapp

I would do:

 1) Release TC 3.3/4.0
 
 2) Start to think on how to merge AJP14/WARP

 3) APRise mod_jk (Adding in a sense you can have a code with/without it via
configure would be a lot more work).

 4) Add the AJP14-WARP protocol to mod_jk and mod_webapp (adaptation)

 5) Add the worker concept to mod_webapp

Because the WARP protocol part of mod_webapp could be used unchanged (or nearly
unchanged) in mod_jk.



Re: IIS Connector for TC4.0

2001-09-14 Thread cmanolache

On Fri, 14 Sep 2001, jean-frederic clere wrote:

  Maybe to you, but buddy Costin doesn't like it... :)
 
  No I'm sure Costin like the merge, and I like
  you all comment the following timing :

I like the merge, I don't like the idea of moving all jk features
over to webapp ( and not on the argument that APR is so difficult
that it makes more sense to do that then using APR in jk and adding
webapp's features ).

  1) Release TC 3.3/4.0

  2) Start to think on how to merge AJP14/WARP

  3) APRise mod_jk (Adding in a sense you can have a code with/without it via
 configure would be a lot more work).

  4) Add the AJP14-WARP protocol to mod_jk and mod_webapp (adaptation)

+1 - that seems a good plan, and we should do it anyway. The result would
be some common code we can share.


  5) Add the worker concept to mod_webapp

+0 on this - with some changes mod_webapp could support all jk
workers, but I'm not sure what would be the use to duplicate.

We can call the result mod_jk_webapp - and will certainly include
all mod_webapp features, but I believe it's much easier ( and better )
to add warp to apr to jk ( rather then add workers, connectors, etc to
webapp ). And we can do that with minimal impact on jk stability.


Costin




Re: IIS Connector for TC4.0

2001-09-14 Thread Pier Fumagalli

GOMEZ Henri [EMAIL PROTECTED] wrote:

 1) Release TC 3.3/4.0

DOH! :)

 2) Start to think on how to merge AJP14/WARP

Let me know when

 3) Add the AJP14-WARP protocol to mod_jk and mod_webapp (adaptation)

I'll keep track of the protocol modifications in TC4 and WebApp

 4) Add APR to mod_jk and worker concept to mod_webapp

Well, the worker seems to be an hybridization of wa_connection+wa_provider.
Basically a big object-like structore holding configuration
(wa_connection) and code (wa_provider)...

Pier





RE: IIS Connector for TC4.0

2001-09-14 Thread GOMEZ Henri

I feel we'll need some schemas on mod_jk workers
and webapp broker to see how to better understand
them :)

-
Henri Gomez ___[_]
EMAIL : [EMAIL PROTECTED](. .) 
PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 



-Original Message-
From: Pier Fumagalli [mailto:[EMAIL PROTECTED]]
Sent: Friday, September 14, 2001 8:10 PM
To: [EMAIL PROTECTED]
Subject: Re: IIS Connector for TC4.0


GOMEZ Henri [EMAIL PROTECTED] wrote:

 1) Release TC 3.3/4.0

DOH! :)

 2) Start to think on how to merge AJP14/WARP

Let me know when

 3) Add the AJP14-WARP protocol to mod_jk and mod_webapp (adaptation)

I'll keep track of the protocol modifications in TC4 and WebApp

 4) Add APR to mod_jk and worker concept to mod_webapp

Well, the worker seems to be an hybridization of 
wa_connection+wa_provider.
Basically a big object-like structore holding configuration
(wa_connection) and code (wa_provider)...

Pier





IIS Connector for TC4.0

2001-09-13 Thread Andy Armstrong

Hi Gal, Developers,

I'm about to produce a webapp version of the Domino connector for TC4.0,
and I see there isn't an IIS connector. Is anyone working on this? Want
me to take a look?

Bye.

-- 
Andy Armstrong, Tagish



Re: IIS Connector for TC4.0

2001-09-13 Thread Andy Armstrong

Andy Armstrong wrote:
 
 Hi Gal, Developers,
 
 I'm about to produce a webapp version of the Domino connector for TC4.0,
 and I see there isn't an IIS connector. Is anyone working on this? Want
 me to take a look?

(Sorry to follow myself up)

Off-list I've had it explained to me that jk is still valid for TC4.0,
so I'll concentrate on testing the jk version of the Domino connector
with 4.0. Sorry for the confusion (all mine).

-- 
Andy Armstrong, Tagish



Re: IIS Connector for TC4.0

2001-09-13 Thread Pier Fumagalli

Andy Armstrong [EMAIL PROTECTED] wrote:

 Hi Gal, Developers,
 
 I'm about to produce a webapp version of the Domino connector for TC4.0,
 and I see there isn't an IIS connector. Is anyone working on this? Want
 me to take a look?

No, I'm not yet working on those. I'm actually concentrating on fixing the
library bugs, the required improvements, and its integration with APR, plus
a bunch of developer docs which will help in refining/extending the WebApp
library API.

It would be so cool to be able to have at least a base code on which to work
on, as Colin gratefully donated his code for NSAPI.

Regarding a long-term plan, I heard Costin and Henri talking about
refactorying the JK connector APIs, and using APR, but that actually nothing
is ready yet (correct me if I'm wrong)...

My alleged thought right now goes to a big input in terms of API design from
the JK guys, I believe (but that's my personal feeling) that if a major
redesign needs to be done in JK land, we can use some of the bases put in
place by WebApp and especially APR, to come out with maybe a new/revised
improved APR-based module...

Let me know your thoughts...

Pier




Re: IIS Connector for TC4.0

2001-09-13 Thread Andy Armstrong

Pier Fumagalli wrote:
 
 Andy Armstrong [EMAIL PROTECTED] wrote:
 
  Hi Gal, Developers,
 
  I'm about to produce a webapp version of the Domino connector for TC4.0,
  and I see there isn't an IIS connector. Is anyone working on this? Want
  me to take a look?
 
 No, I'm not yet working on those. I'm actually concentrating on fixing the
 library bugs, the required improvements, and its integration with APR, plus
 a bunch of developer docs which will help in refining/extending the WebApp
 library API.
 
 It would be so cool to be able to have at least a base code on which to work
 on, as Colin gratefully donated his code for NSAPI.
 
 Regarding a long-term plan, I heard Costin and Henri talking about
 refactorying the JK connector APIs, and using APR, but that actually nothing
 is ready yet (correct me if I'm wrong)...
 
 My alleged thought right now goes to a big input in terms of API design from
 the JK guys, I believe (but that's my personal feeling) that if a major
 redesign needs to be done in JK land, we can use some of the bases put in
 place by WebApp and especially APR, to come out with maybe a new/revised
 improved APR-based module...
 
 Let me know your thoughts...

Urm. I'm keen to be guided by people who have a better overview of where
connectors are headed in general and what needs doing really. My
priority is to make sure the current Domino/JK connector works OK with
TC4.0. Once that's nailed I'm open to suggestions. I'd be happy to
produce a wepapp version of the Domino connector, but I'm also happy to
undertake any work that needs doing on the IIS connector (I'm not
suggesting there /is/ work to do on IIS -- it's just something I could
quite easily do).

As usual I'm also pondering why I'm spending so much time on IIS and
Domino when I wouldn't run anything apart from Apache if I ruled the
world. I wonder what I did in a past life...

-- 
Andy Armstrong, Tagish



Re: IIS Connector for TC4.0

2001-09-13 Thread Pier Fumagalli

Andy Armstrong [EMAIL PROTECTED] wrote:

 Andy Armstrong wrote:
 
 Hi Gal, Developers,
 
 I'm about to produce a webapp version of the Domino connector for TC4.0,
 and I see there isn't an IIS connector. Is anyone working on this? Want
 me to take a look?
 
 (Sorry to follow myself up)
 
 Off-list I've had it explained to me that jk is still valid for TC4.0,
 so I'll concentrate on testing the jk version of the Domino connector
 with 4.0. Sorry for the confusion (all mine).

Well, the effort for bringing any connector to WebApp is kinda big, I mean,
basically every API used there MUST follow APR counterparts (no ANSI-C), so
I'd see it as a long-term plan for APR-ization of the connector world...

Pier




Re: IIS Connector for TC4.0

2001-09-13 Thread cmanolache

On Thu, 13 Sep 2001, Pier Fumagalli wrote:

 Regarding a long-term plan, I heard Costin and Henri talking about
 refactorying the JK connector APIs, and using APR, but that actually nothing
 is ready yet (correct me if I'm wrong)...

 My alleged thought right now goes to a big input in terms of API design from
 the JK guys, I believe (but that's my personal feeling) that if a major
 redesign needs to be done in JK land, we can use some of the bases put in
 place by WebApp and especially APR, to come out with maybe a new/revised
 improved APR-based module...

My view:

It should happen only after 3.3 (and 4.0) is released, switching to APR is
reasonably easy ( IMHO ), adding warp protocol is doable ( but require
some changes in the request representation to use the same struct as the other
jk modules ).

Integrating WARP and AJP14 seems easy ( technically - there are many
common things ), but it'll require some 'negotiation' - and I hope some
real community involvment.

Refactoring/cleaning of jk - one part will be done by the move to APR
( of course ), there are some optimizations and improvements in the jni
connector I am planning ( also after APR is in ), and some of the webapp
API ( and docs :-) could also help a lot.

And of course, I'm happy to see both Pier and Henri are open.

Costin







Re: IIS Connector for TC4.0

2001-09-13 Thread Pier Fumagalli

[EMAIL PROTECTED] [EMAIL PROTECTED] wrote:

 My view:
 
 It should happen only after 3.3 (and 4.0) is released, switching to APR is
 reasonably easy ( IMHO ), adding warp protocol is doable ( but require
 some changes in the request representation to use the same struct as the other
 jk modules ).

Well, for 4.0 it's pretty easy... It doesn't ship with a connector, only the
WARP java counterpart... I don't want to touch 3.3 in terms of their plans.

Anyway, switching to APR is not that easy (IMO), if you want to take
advantage of ALL which is provided by APR (I'm deprecating ANSI-C here).

 Integrating WARP and AJP14 seems easy ( technically - there are many
 common things ), but it'll require some 'negotiation' - and I hope some
 real community involvment.

C'mon... It _IS_ the easiest thing... We just need to adjust those routines
to read/send packets, and what packet is used for what... The easiest thing
is to implement the real protocol... All hard work is about how that data
is organized within the respective modules, not how to grab it and put it on
the network... And being the author of 2 out of 3 connectors on this
project, I know what I'm talking about :) :) :)

 Refactoring/cleaning of jk - one part will be done by the move to APR
 ( of course ), there are some optimizations and improvements in the jni
 connector I am planning ( also after APR is in ), and some of the webapp
 API ( and docs :-) could also help a lot.

DOH! I'm saying, let's refactor WebApp how you guys want it... In the past 6
months I got to know APR quite well, on the other hand, you guys have more
experience on the different web-servers... We have a working APR-based
implementation, let's just put it together in a nice way so that it fits
BOTH needs...

 And of course, I'm happy to see both Pier and Henri are open.

DOH! I've always been... :)

Pier




Re: IIS Connector for TC4.0

2001-09-13 Thread cmanolache

On Fri, 14 Sep 2001, Pier Fumagalli wrote:

 Anyway, switching to APR is not that easy (IMO), if you want to take
 advantage of ALL which is provided by APR (I'm deprecating ANSI-C here).

This is an incremental process, and can only increase the stability of jk.

  Refactoring/cleaning of jk - one part will be done by the move to APR
  ( of course ), there are some optimizations and improvements in the jni
  connector I am planning ( also after APR is in ), and some of the webapp
  API ( and docs :-) could also help a lot.

 DOH! I'm saying, let's refactor WebApp how you guys want it... In the past 6
 months I got to know APR quite well, on the other hand, you guys have more
 experience on the different web-servers... We have a working APR-based
 implementation, let's just put it together in a nice way so that it fits
 BOTH needs...

It doesn't make too much sense. You're saying we should use WebApp because
it already uses APR, and port back all the protocols and modules to it.

I don't know - if using APR is so difficult that it's easier to port all
the modules to webapp rather than replace the C functions with the APR
equivalent in jk - then maybe we should thing again about using APR.

But my impression so far is that APR is quite easy to use and very close
to the current abstractions used in jk.

Costin




Re: IIS Connector for TC4.0

2001-09-13 Thread Pier Fumagalli

[EMAIL PROTECTED] [EMAIL PROTECTED] wrote:

 On Fri, 14 Sep 2001, Pier Fumagalli wrote:
 
 At the same time, since also JK is moving towards APR, but they're far
 behind what WebApp does ATM, let's try to refine/update/change the WebApp
 API, already based on APR, and work on it as the APR based connector, when
 that is ready, we can think about porting all nice stuff that are still
 missing (load balancing, JNI and such), over to the new architecture...
 
 
 Pier, APR is a library of portable code - not a new 'architecture'. Mod_jk
 has an API that is used with 4 different protocols ( webapp will be the
 5th ), 4 different web servers. This architecture is pretty well tested
 and stable.
 
 I'm not sure I understand your idea - of moving all this into webapp,
 instead of moving warp as a jk protocol ( or integrate it with ajp14).

I'm just saying that APR is not the easiest bitch to handle on this
planet... And I've given my full support since it seems that you guys want
to refactor the JK api and use APR... Since there is already a working
connector based on APR, and you're refactorying the JK API, I thought it
might have been wise to use the already working APR-ized connector as a
starting point. I don't mind rewriting the full WebApp core if it's worth
to, it doesn't scare me...

I'm just trying to be the nice guy around here, simply saying part of it is
there, and if you guys want, I'm more than welcome to turn the sucker inside
out... Trying to avoid duplicate work...

If that's against your way of working, well, I'm just going to go ahead my
own way. I simply thought that the one mentioned above was a win-win
situation...

But as always, if you don't want to, well, whatever :) We're just going to
go on and re-duplicate work over and over again... WebApp, as JServ, (and
3.3 for you?) is my baby, and I'm not going to abandon it, even if you guys
kick me out :)

I just said that if you want to APR-ize JK and change the API, well, maybe
we can see to lay the grounds for new foundations?

Pier




Re: IIS Connector for TC4.0

2001-09-13 Thread Pier Fumagalli

[EMAIL PROTECTED] [EMAIL PROTECTED] wrote:

 On Fri, 14 Sep 2001, Pier Fumagalli wrote:
 
 Anyway, switching to APR is not that easy (IMO), if you want to take
 advantage of ALL which is provided by APR (I'm deprecating ANSI-C here).
 
 This is an incremental process, and can only increase the stability of jk.

You'll see :) APR is nice, but I believe that, as it's wrong to write C++
code in Java, so it's wrong to port stuff to APR... Once you discover the
APR platform, if you want to take full advantage of it, you have to THINK
APR...

 Refactoring/cleaning of jk - one part will be done by the move to APR
 ( of course ), there are some optimizations and improvements in the jni
 connector I am planning ( also after APR is in ), and some of the webapp
 API ( and docs :-) could also help a lot.
 
 DOH! I'm saying, let's refactor WebApp how you guys want it... In the past 6
 months I got to know APR quite well, on the other hand, you guys have more
 experience on the different web-servers... We have a working APR-based
 implementation, let's just put it together in a nice way so that it fits
 BOTH needs...
 
 It doesn't make too much sense. You're saying we should use WebApp because
 it already uses APR, and port back all the protocols and modules to it.

I'm saying that, since in your previous messages you said you wanted to
refactor the JK api, and port it to APR, well, why not considering a new
planning ground?

The WebApp API at the moment is _so_ tiny that can be changed, revolted,
destroyed and rebuilt with no problems in a reasonable amount of time...

 I don't know - if using APR is so difficult that it's easier to port all
 the modules to webapp rather than replace the C functions with the APR
 equivalent in jk - then maybe we should thing again about using APR.

Your choice... Mine was to use APR as my platform forgetting everything I
knew about C...

 But my impression so far is that APR is quite easy to use and very close
 to the current abstractions used in jk.

You're welcome to go ahead and do whatever you want... I'm not vetoing (as
always)... I'm just being propositive...

Pier (the nice guy?)