mod_cvs in apache 2.0, apr questions

[Ben Peter <be...@gmx.net>]

Apache developers,

the maintainer of mod_cvs has no plans for porting mod_cvs to apache 2.0. I
would have a peek in the apache sources and try to accomplish this task.
mod_cvs checks the file to be served against a CVS repository before it is
served.

As to the strategy, I would prefer to have some input from developers that
have a deeper knowlege of the overall architecture.

Two strategies have come to my mind:

The most straightforward approach after a look at the sources would probably
be to integrate the checks with the apr_open call. This is closest to the os
file access.
However, I realise that this is an utterly ugly approach and could not be
realised as a module.

I am unsure about the second approach, as I have not fully understood the
core filters that apply for request and not found the spot where the file to be
served is opened. The approach would then be to insert a filter before the
file is opened and do cvs checks from there.

The realisation as a filter has one deficiency: it does not intercept files
that are opened by other modules (e.g. a PHP include() statement). That is
what lead to my initial approach of integrating with apr_open(). 

Any suggestions on this topic would be greatly appreciated.

Thanks in advance,
Ben

-- 
Ben Peter
ph. +49-(0)173-9262278
fax +49-(0)89-1488-216649

Re: mod_cvs in apache 2.0, apr questions

["Paul J. Reder" <re...@raleigh.ibm.com>]

"William A. Rowe, Jr." wrote:
> It runs every filename through the subrequest mechanism.  You will find very
> similar logic scattered throughout the server.  SSI Includes is another
> good example.

SSI does not handle all of its directives through subrequests. The directive
"flastmod", for example, sets up a subreq (to get the stat info) but never
runs the subrequest (it got what it wanted). The cvs setup would have trouble
intercepting this to use the info from cvs instead.

On the other hand, wouldn't a small cvs_filter be able to watch for any
file buckets and easily check them against cvs? I know that doesn't satisfy
all of the aspects of what mod_cvs might try to provide, but it might be 
a start.

-- 
Paul J. Reder
-----------------------------------------------------------
"The strength of the Constitution lies entirely in the determination of each
citizen to defend it.  Only if every single citizen feels duty bound to do
his share in this defense are the constitutional rights secure."
-- Albert Einstein

Re: mod_cvs in apache 2.0, apr questions

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

Ben,

  subrequests are all passed through the same set of hooks as the primary
request.  So, where a module is well designed to invoke itself through the
subrequests, you are in business.

  For example, see mod_autoindex (a place where you might want to report
the very latest date from cvs, rather than the current file's date.)  It
runs every filename through the subrequest mechanism.  You will find very
similar logic scattered throughout the server.  SSI Includes is another
good example.

  The problem I see in what you want to do to apr_open is very dicey.  You
are 'injecting' yourself into the platform-dependent mechanics, which is
definately -not- where you want to be, and consuming far more cpu than you
probably need.

  Good luck!

Bill

Re: mod_cvs in apache 2.0, apr questions

[Greg Stein <gs...@lyra.org>]

While true, that is a pretty drastic change across all of Apache. It isn't
restricted to just a single module. Apache is too hard-wired to the
filesystem. After 2.0, I'm hoping to figure out a way to untie it from the
FS so that a resource can come from any logical source.

[ I do some content serving in a repository independent manner in mod_dav,
  but it is a far cry from what is truly needed. ]

Cheers,
-g

On Thu, Jan 25, 2001 at 03:00:33PM +0100, Ben Peter wrote:
> Greg,
> 
> I have read the instructions for a quick port and I don't think this will
> raise any problems. Still, mod_cvs is far more useful if it checks not only
> static files that are served, but also files included in some way or the other.
> 
> Ben
> 
> > Don't try rearchitecting it. Just do a quick port. You'll have some symbol
> > renames, some hook registration, and a bit of difference in how your
> > handler
> > is called. But the general code flow will *still* work.
> > 
> > You don't have to switch to apr_open, you don't have to use filters, etc.
> > 
> > Cheers,
> > -g
> > 
> > On Thu, Jan 25, 2001 at 02:06:52PM +0100, Ben Peter wrote:
> > > Apache developers,
> > > 
> > > the maintainer of mod_cvs has no plans for porting mod_cvs to apache
> > 2.0. I
> > > would have a peek in the apache sources and try to accomplish this task.
> > > mod_cvs checks the file to be served against a CVS repository before it
> > is
> > > served.
> > > 
> > > As to the strategy, I would prefer to have some input from developers
> > that
> > > have a deeper knowlege of the overall architecture.
> > > 
> > > Two strategies have come to my mind:
> > > 
> > > The most straightforward approach after a look at the sources would
> > probably
> > > be to integrate the checks with the apr_open call. This is closest to
> > the os
> > > file access.
> > > However, I realise that this is an utterly ugly approach and could not
> > be
> > > realised as a module.
> > > 
> > > I am unsure about the second approach, as I have not fully understood
> > the
> > > core filters that apply for request and not found the spot where the
> > file to be
> > > served is opened. The approach would then be to insert a filter before
> > the
> > > file is opened and do cvs checks from there.
> > > 
> > > The realisation as a filter has one deficiency: it does not intercept
> > files
> > > that are opened by other modules (e.g. a PHP include() statement). That
> > is
> > > what lead to my initial approach of integrating with apr_open(). 
> > > 
> > > Any suggestions on this topic would be greatly appreciated.
> > > 
> > > Thanks in advance,
> > > Ben
> > > 
> > > -- 
> > > Ben Peter
> > > ph. +49-(0)173-9262278
> > > fax +49-(0)89-1488-216649
> > 
> > -- 
> > Greg Stein, http://www.lyra.org/
> > 
> 
> -- 
> Ben Peter
> ph. +49-(0)173-9262278
> fax +49-(0)89-1488-216649

-- 
Greg Stein, http://www.lyra.org/

Re: mod_cvs in apache 2.0, apr questions

[Ben Peter <be...@gmx.net>]

Greg,

I have read the instructions for a quick port and I don't think this will
raise any problems. Still, mod_cvs is far more useful if it checks not only
static files that are served, but also files included in some way or the other.

Ben

> Don't try rearchitecting it. Just do a quick port. You'll have some symbol
> renames, some hook registration, and a bit of difference in how your
> handler
> is called. But the general code flow will *still* work.
> 
> You don't have to switch to apr_open, you don't have to use filters, etc.
> 
> Cheers,
> -g
> 
> On Thu, Jan 25, 2001 at 02:06:52PM +0100, Ben Peter wrote:
> > Apache developers,
> > 
> > the maintainer of mod_cvs has no plans for porting mod_cvs to apache
> 2.0. I
> > would have a peek in the apache sources and try to accomplish this task.
> > mod_cvs checks the file to be served against a CVS repository before it
> is
> > served.
> > 
> > As to the strategy, I would prefer to have some input from developers
> that
> > have a deeper knowlege of the overall architecture.
> > 
> > Two strategies have come to my mind:
> > 
> > The most straightforward approach after a look at the sources would
> probably
> > be to integrate the checks with the apr_open call. This is closest to
> the os
> > file access.
> > However, I realise that this is an utterly ugly approach and could not
> be
> > realised as a module.
> > 
> > I am unsure about the second approach, as I have not fully understood
> the
> > core filters that apply for request and not found the spot where the
> file to be
> > served is opened. The approach would then be to insert a filter before
> the
> > file is opened and do cvs checks from there.
> > 
> > The realisation as a filter has one deficiency: it does not intercept
> files
> > that are opened by other modules (e.g. a PHP include() statement). That
> is
> > what lead to my initial approach of integrating with apr_open(). 
> > 
> > Any suggestions on this topic would be greatly appreciated.
> > 
> > Thanks in advance,
> > Ben
> > 
> > -- 
> > Ben Peter
> > ph. +49-(0)173-9262278
> > fax +49-(0)89-1488-216649
> 
> -- 
> Greg Stein, http://www.lyra.org/
> 

-- 
Ben Peter
ph. +49-(0)173-9262278
fax +49-(0)89-1488-216649

Re: mod_cvs in apache 2.0, apr questions

[Greg Stein <gs...@lyra.org>]

Don't try rearchitecting it. Just do a quick port. You'll have some symbol
renames, some hook registration, and a bit of difference in how your handler
is called. But the general code flow will *still* work.

You don't have to switch to apr_open, you don't have to use filters, etc.

Cheers,
-g

On Thu, Jan 25, 2001 at 02:06:52PM +0100, Ben Peter wrote:
> Apache developers,
> 
> the maintainer of mod_cvs has no plans for porting mod_cvs to apache 2.0. I
> would have a peek in the apache sources and try to accomplish this task.
> mod_cvs checks the file to be served against a CVS repository before it is
> served.
> 
> As to the strategy, I would prefer to have some input from developers that
> have a deeper knowlege of the overall architecture.
> 
> Two strategies have come to my mind:
> 
> The most straightforward approach after a look at the sources would probably
> be to integrate the checks with the apr_open call. This is closest to the os
> file access.
> However, I realise that this is an utterly ugly approach and could not be
> realised as a module.
> 
> I am unsure about the second approach, as I have not fully understood the
> core filters that apply for request and not found the spot where the file to be
> served is opened. The approach would then be to insert a filter before the
> file is opened and do cvs checks from there.
> 
> The realisation as a filter has one deficiency: it does not intercept files
> that are opened by other modules (e.g. a PHP include() statement). That is
> what lead to my initial approach of integrating with apr_open(). 
> 
> Any suggestions on this topic would be greatly appreciated.
> 
> Thanks in advance,
> Ben
> 
> -- 
> Ben Peter
> ph. +49-(0)173-9262278
> fax +49-(0)89-1488-216649

-- 
Greg Stein, http://www.lyra.org/