Unfortunately, I clipped some of Bruce's original email, so it isn't all
here, and I don't have the original. Anyhow, Bruce said it is okay to
forward this.
I'm posting it here simply because *others* may benefit beyond just Bruce
and myself.
Cheers,
-g
----- Forwarded message from Greg Stein <gstein@lyra.org> -----
From: Greg Stein <gstein@lyra.org>
Subject: Re: A few ideas concerning Subversion
To: Bruce Atherton <bruce@hagbard.flair.law.ubc.ca>
Date: Thu, 1 Mar 2001 15:46:39 -0800
[ note: your reply wasn't copied to the SVN list; I'm not sure of your
intent, so I didn't take that liberty; so I'm responding in kind. please
feel free to repost your response to the SVN list and forward mine at your
leisure (or I can bounce mine, too) ]
On Thu, Mar 01, 2001 at 03:12:07PM -0800, Bruce Atherton wrote:
> Thanks for your response to my ideas.
>
> > Well, that's because most of the architecture is somewhat settled,
> > and we're now executing on it :-)
>
> Yes, I realize that I am a little late to the discussion. Still,
> better late than never, right?
Of course! I'm not trying to shut down idea generation, so much as two
things:
1) we are trying to be extremely pragmatic: do what needs to be done to
replace CVS [functionality] but no more
2) avoid distraction and focus on (1)
As long as people contributing ideas are aware that this is occurring, then
we'll all be happy :-)
>...
> >Quite doable, and Ryan Bloom is actually doing some work this week to
> >improve the multiprotocol support. While doc will certainly be lacking
> >for a while, this will be entirely doable.
> >(it's doable now, but somewhat difficult; Ryan is untangling code so
> >the non-HTTP-specific support/framework can be used)
>
> I've been following the apache-modules list, but haven't seen anything
> that looks too helpful. Perhaps I should just pose the question.
Bleh. I'm thinking about unsubscribing to apache-modules. Mostly, I just see
people who don't take the time to read docs or code or think for themselves.
new-httpd is where all the development and design occurs for the core
server, which is the relevant point here. It isn't really about "how do I
write this module?" but that should be fine.
> >Seems doable. I'd go with the Apache approach over Avalon :-)
>
> Is that from experience? Do you just prefer C over Java? Or do you
> know something about the Avalon framework I should be aware of?
I prefer C over Java. I also know that Apache 2.0 will be hands-down more
scalable, portable, faster, etc across a helluva lot more platforms than
Avalon. Avalon is only good for people who choose to use Java as their
server construction language.
For example, can you control Linux's TCP_CORK flag from Avalon/Java? How
about lingering close? Should your app be process-based? Thread-based? Or a
blend of the two? Are you able to do that? For the platform at hand, is
shared memory available for interprocess communication? When you accept() on
a socket, can you do that from multiple processes? Do you need to set any
flags to prevent the "thundering herd" problem?
etc. ad nauseum
Avalon just can't touch Apache 2.0 in terms of building quality servers.
Apache 2.0's benefits are also why it was chosen as the server framework for
Subversion. There was no way we wanted to duplicate all that complexity in
our own server. We wanted to choose something, and it was pretty obvious :-)
And note: this is all moot. You don't need this kind of performance for a
CVS pserver proxy. 1) SVN will inherently make it much faster than CVS
pserver. 2) if people complain, tell them to shut up and switch to SVN.
> >There is a simpler approach, which is the style used by CVS pserver
> >itself. Use the inetd network daemon system. Basically, your program
> >is started with a network socket hooked to stdin/stdout.
> >
> >Below, you mention language APIs. Assume you have a Perl or Python
> >API to libsvn_fs. Write a script to suck in pserver requests from
> >stdin, process against libsvn_fs, then write the results to stdout.
>
> Thanks for the idea. This may very well be the best way to go. Only
> trouble is that my most comfortable language is Java. Still, this might
> be a good project for me to throw myself into Python, which I've only
> played with up to now.
Well, Java can read/write stdin/stdout, right? You should be able to do it.
You would need those JNI bindings, though.
Personally, I'd recommend Python without qualification. For this task, it is
(IMO) ideally suited.
> >I've talked with Paul Everitt (their CEO) about stuff along these
> >lines. They're certainly thinking about it, and *especially* w.r.t
> >Subversion.
>
> That's interesting news. I hadn't realized that support for Subversion
> was becoming broadbased. I'm very glad to hear it.
Oh, there is a lot of support for Subversion in all kinds of places. It is
quite neat, actually :-) CVS doesn't stand a chance :-)
> >We aren't at a stage where the code is usable, so doc certainly
> >isn't needed for users. It might be nice for developers, but I'm not
> >too worried about that either. We've seen plenty of people come on
> >board with the current doc.
>
> It's true that you can figure stuff out from the source, but speaking
> as a developer who is trying to come up to speed on this, it would
> certainly lower the barriers to entry if the documentation was more
> complete and accurate.
I totally agree that it would reduce the barriers. No question. But needing
the lower barriers is premised on needing more developers :-) Truthfully,
we're pretty well maxxed out on the FS side of things; I'm not sure we could
manage more fingers in that code. I wouldn't mind another developer
assisting with the network coding (I can keep up with the other guys, but
I'd prefer another pair of eyes in my work at least to ensure that somebody
else agrees with my directions). Some client side developers would be nice,
but that'll bulk back up as soon as the FS becomes workable.
In any case. I'm not suggesting that we *want* to keep any barriers to
entry. I'm merely stating that (IMO) we don't have a strong motivation to
take the time/energy to lower them right now.
> I'm not even suggesting that the coders be
> responsible for keeping it that way necessarily. That is the beauty
> of a Wiki. Each new developer can read the documentation, figure out
> how the code works from there, and then update the documentation to
> help others with the insights they may have had to glean from the code.
Setting up a Wiki would be good, but I'd actually prefer the approach taken
by the PHP documentation -- people can add annotations. That is much "safer"
in my mind than the unstructured editing of a Wiki. Especially when you
consider your suggestion of *new* people doing those changes. Are you sure
they got it right? :-)
The long-term developers can then fold the annotations back into the main
doc at various times.
>...
> >> f) Staying flexible enough for alternate uses
> >
> >This isn't very "actionable", so I can't comment.
>
> Fair enough. I just think it is always a good idea to keep in mind
> that people are going to dream up uses you hadn't considered, and it is
> a good idea to keep things as flexible as possible. Goes against
> Extreme Programming practices, but I find it a good policy anyway.
XP is horrible. It is unrealistic, unproductive, and is not best practices.
It has garned some decent press lately, but it sucks.
But that is beside the point. I totally agree that it is nice to allow for
all kinds of experimentation. It is just hard to take that as an action
item. How can you objectively identify the points where extending is "hard"?
We can keep it in mind, but there aren't specific designs to follow to
achieve this goal.
> >I'll personally be ensuring there is a Python library.
>
> So Python would be a good choice for a CVS proxy, then.
Absolutely. I'd recommend implementation with a stub module for wrapping
libsvn_fs. That will let you handle the protocol issues without worrying
about whether Python bindings have been built (yet).
>...
> >Ideas are fine, but recognize that we already have an end goal in
> >mind with a limited/targeted feature set. In that sense, about the
> >best we can do is to take your ideas and drop them into the IDEAS
> >file. Submitting ideas as a patch against the file is a sure bet :-)
>
> I wouldn't presume. I'm just a newcomer here, throwing out ideas
> willy-nilly with no idea how relevant they truly are to what you are
> doing. So I'll let you developers decide which are worth saving for
> posterity and which are just the product of an uninformed mind.
Go ahead and presume. Just understand (1) and (2) above. Ideas are always
welcome; it is just that (pragmatically speaking) we will tend to want to
ignore them if they aren't low-hanging fruit or they can't be done in
parallel/independently by new/other developers.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
----- End forwarded message -----
--
Greg Stein, http://www.lyra.org/
Received on Sat Oct 21 14:36:24 2006