Re: New HTTP Protocol (was re: svn commit: r33365)

[Ben Collins-Sussman <su...@red-bean.com>]

On Tue, Sep 30, 2008 at 6:47 PM, Mark Phippard <ma...@gmail.com> wrote:
> On Tue, Sep 30, 2008 at 6:50 PM, Ben Collins-Sussman
> <su...@red-bean.com> wrote:
>>> A little confused by this last sentence.  There are three points
>>> included in it.  Wouldn't the first one be the only one that required
>>> mod_dav_svn?  It seems like this new library could work as well, or
>>> better with the other two.
>>
>> You're right.  See the other thread with comments from gstein -- he's
>> pushing for cacheability as a feature, and there's no reason a
>> well-designed new protocol couldn't be designed for that (or write
>> proxying).
>
> An advantage to the current ra_serf "GET-based" design, besides
> caching, is access logging.  It is very easy to see how often specific
> resources are being accessed.  Current REPORT-based operations mask
> this.  We had one customer (perhaps it will only ever be one) that
> wanted this.

I think this indicates that the logging should be pushed down into the
fs layer, rather than living solely at the server-level.

When somebody implements detailed logging for svnserve (inevitably),
they're going to run into the same problem, and I'm pretty sure
they're not going to redesign the protocol to make lots of little
cacheable fetches, rather than single streaming responses.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: New HTTP Protocol (was re: svn commit: r33365)

[Branko Čibej <br...@xbc.nu>]

steven higgan wrote:
>
>     Is there a demand for an IIS plugin?  I've never heard of one, but
>     you're the one hearing from corporate customers.
>
>
> apologies Ben, I hit reply instead of Reply all - smacks forehead !!
>
> being one of those corporate people - the answer to your question is a
> definite yes.
>
> i know Apache is good, but at the end of the day if we can get svn
> going over IIS it would be as its one less piece of infrastructure
> that needs to be looked after.

Well you can always get rid of IIS now and win. :)
  /. press



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: New HTTP Protocol (was re: svn commit: r33365)

[steven higgan <st...@gmail.com>]

On Wed, Oct 1, 2008 at 11:50 AM, Ben Collins-Sussman
<su...@red-bean.com>wrote:

> On Tue, Sep 30, 2008 at 5:12 PM, Mark Phippard <ma...@gmail.com> wrote:
> > It seems like if we architected this right, it would not be too hard
> > for someone to create an IIS add-in that also supported this feature.
> > Ideally, the real work would be in a reusable library for the Apache
> > module and maybe even svnserve and an IIS version could be created
> > that used the same library?
>
> Is there a demand for an IIS plugin?  I've never heard of one, but
> you're the one hearing from corporate customers.
>

apologies Ben, I hit reply instead of Reply all - smacks forehead !!

being one of those corporate people - the answer to your question is a
definite yes.

i know Apache is good, but at the end of the day if we can get svn going
over IIS it would be as its one less piece of infrastructure that needs to
be looked after.

since your basically making a 'subversion web-service' sending xml over the
wire (im guessing this, i havent read your doc - its on the 'todo' list), I
can already imagine an ocean of clients using it.

Re: New HTTP Protocol (was re: svn commit: r33365)

[Mark Phippard <ma...@gmail.com>]

On Tue, Sep 30, 2008 at 8:09 PM, Ben Collins-Sussman
<su...@red-bean.com> wrote:
> On Tue, Sep 30, 2008 at 6:47 PM, Mark Phippard <ma...@gmail.com> wrote:
>> On Tue, Sep 30, 2008 at 6:50 PM, Ben Collins-Sussman
>> <su...@red-bean.com> wrote:
>>>> A little confused by this last sentence.  There are three points
>>>> included in it.  Wouldn't the first one be the only one that required
>>>> mod_dav_svn?  It seems like this new library could work as well, or
>>>> better with the other two.
>>>
>>> You're right.  See the other thread with comments from gstein -- he's
>>> pushing for cacheability as a feature, and there's no reason a
>>> well-designed new protocol couldn't be designed for that (or write
>>> proxying).
>>
>> An advantage to the current ra_serf "GET-based" design, besides
>> caching, is access logging.  It is very easy to see how often specific
>> resources are being accessed.  Current REPORT-based operations mask
>> this.  We had one customer (perhaps it will only ever be one) that
>> wanted this.
>
> I think this indicates that the logging should be pushed down into the
> fs layer, rather than living solely at the server-level.
>
> When somebody implements detailed logging for svnserve (inevitably),
> they're going to run into the same problem, and I'm pretty sure
> they're not going to redesign the protocol to make lots of little
> cacheable fetches, rather than single streaming responses.

There is logging for svnserve in trunk.  To my knowledge it is the
same sort of operational logging that we have in Apache.  But your
point is fair nonetheless.

-- 
Thanks

Mark Phippard
http://markphip.blogspot.com/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org