On Tue, 29 Aug 2000, Justin Wells wrote:

> On Mon, Aug 28, 2000 at 06:03:37AM -0400, Jason van Zyl wrote:
> > Just as there are many implementations of JSP, C, C++, Java and
> > every other language that exists, so are there now of WebMacro.
> 
> Except there's no guarantee they'll really be compatible, and it 
> creates confusion. It splits the available resources, and it makes
> people think they made a mistake using free software. 

Of course there is? It's called a testbed. And it's not like
this is Java where you need a complicated mechanism like
the JCK. This thing is not complicated. A few hundred lines
of a template, some JUnit tasks to verify the API and you're
done. You make this sound far more complicated then it is
and you are being misleading.
 
> > In terms of WebMacro users, I think Velocity is a benefit
> > as well. We have full intentions of trying to make Velocity
> > a 100% drop in replacement for WebMacro.
> 
> Let's not make this an "eventual" thing, let's make it happen 
> this week. Let's put the two projects together and create one 
> fully functional unified code tree with everything in it. 

I've looked at your code and it's definitely not going to
happen this week. We've taken almost entirely different
approaches. I think Jason Hunter was correct in his
assessment that it's not necessarily a mingling of
code that is most benficial but a mingling of
experience. I will definitely not endorse a
forced merger of code to suit your needs.

You make it sound like WebMacro users will be in dire
straights if we continue with Velocity and that's simply
not true. None of developers currently on the contributors
list have ever worked on WebMacro. So you didn't lose
any developers. The developer community wasn't fractured.
Your current users will get what they have been
getting up to this point in time. Basically you developing
WM by yourself, you obviously got help from your
users but how many others developers did work in
close contact with on a regular basis? That's what your users have to
ask themselves, do they want to continue with something
that might be critical to their needs being developed
primarily by a single person. Already in Velocity
the other developers are catching up to me rapidly
in terms of total contribution. I did the initial work
but there is already diversity in the code base.

> You'll then have my help improving it over time. My need is that
> what we have by the end of this week support my clients, like 
> AltaVista, who depend on all kinds of interfaces that WM has 
> which you haven't yet adopted and may not for a long time. 

You can help as much as you want over time. 
But your requirement of satisfying your clients needs
are your problem right now, not ours. To say that in
order for Velocity to be successfull it must satisfy
the requirements of all WebMacro users is ridiculous.
Use WebMacro then, Velocity will be released when it
is ready. I don't imagine that will be very long,
but it's certainly not going to be next week. The
WM code that makes it into the Velocity code base
will be added at a pace that keeps Velocity stable.

I have committed to making Velocity compatible with
WebMacro on an agreed upon API, but we're not guaranteeing
that that will happen next week. Even if you jumped
in full bore that wouldn't happen.

> By the way, it's no longer a secret that AltaVista is evaluating
> WebMacro. They haven't made an official decision to use Java/WebMacro
> for the AltaVista site, but it is pretty much the leading contender
> at this point. Wouldn't you like to be a part of that? If we make
> it one unified code base you will be.

Not at the cost of a forced merger of the code bases to
satisfy AltaVista specifically. AltaVista is your problem,
not ours. Your short terms requirements are not our short
term requirements.

> Not only that, but AV has a lot of resources to put back in. This
> also pretty much gives WM better name recognition than Velocity,
> since being used on AV will a huge PR win--if we can pull it off.

I don't think so. Who has greater recognition in the developer
community the ASF or AltaVista. And with the ASF working
closely with Collab and SourceXchange it is probably more
true that corporate interests fully recognize the
value in using software developed by ASF projects.

Although I would like AltaVista to use Velocity it certainly
isn't going to be ready for them next week. 

> > The second that you fully APL your code, or 
> > the second someone at the ASF says it's ok
> > I can then look at your code, we can work together
> > and make something awesome!
> 
> I'll remove the advertising clause and use the nwe ASF license if 
> we can come to some basic understanding about the future. That
> includes deciding that we do want to continue to support people
> like AltaVista.
> 
> Instead of working to rewrite WM, I would like to put the WM code
> into your tree and work on adding your improvements to it. The
> difference is subtle but important: We will be supporting and
> improving an *existing* user base, rather than trying to copy
> soemthing. 

It is almost complete, so we're not really rewriting anything,
I'm improving it. And I'm completely interested in supporting
the WebMacro user base but it's not going to be in the next
week.

> > You can't convince me that the SPL, or a slightly
> > modified APL will not cause problems down the road.
> 
> WebMacro is under the older Apache license with the advertising
> clause, but it *is* the Apache license. I will move to the 
> newer apache license if we can agree on the future.
> 
> > By my last measurement Velocity was slightly faster
> > then your last snapshot. But when I am finished
> > implementing the "Injectors" in Velocity then
> > we will let the profiler/JMeter decide.
> 
> There's only one sane measure and that's requests per second.
> And it's only fair to compare them when they're doing the
> same things, meaning that you have the same flexibility 
> and the same utility.

> > I am a bit of a performance junkie, but I fully realize the
> > quality of the code is just as important and
> > that's why I'm lucky that there are other great
> > developer on the team!
> 
> Put it this way: I've already proven here at AltaVista that 
> WebMacro is capable of serving 100 million pages per day. 

That's fine. Then it will strictly be an issue of code
quality. That is perfectly fine with me.

> There is no performance issue here. There used to be, but 
> it's been solved. At 800 requests per second off a single 
> box there just isn't much more performance ou need.
> 
> > That's about all I have to say on the subject.
> > You are welcome here anytime!
> 
> I can't come and join you unless I can bring my users and know that
> I haven't let them down: they must *immediately* be fully supported, 
> with a mature project and a stable code base.

Not going to happen, and least not with my support. We need
time to evaluate what parts of WM are suitable for
merging. They are different beasts.

> We have to start from WM and add on Velocity stuff, like your parser.

I am working in the other direction. I'm not starting with
your code base. We are six developers and by the end of the
month with the code base being so small most of them
will have a very good understanding of how all the Velocity
code works. Your code base is significantly larger and
you have done it primarily on your own, development wise.
So from a development standpoint it doesn't make much 
sense to me to start with WM. It makes much more sense to
start with Velocity. In terms of your users, I have to
stress that their needs will not be met in the short
term by Velocity. The goal initially was to provide a
solid replacement for WebMacro, not a solid replacement
in a month.

That you have changed the license is great. It means that
we can work together. But you have to remember one thing
and that's that I dropped everything I was doing which
cost me more then money because I couldn't distribute
WebMacro with Turbine. I lost a client that I will
never get back. I never made an issue of it,
or complained on the mailing lists. I did something
about it, and I took matters in to my own hands. I
am really not prepared to put them back into yours.

That you claim not to have known what the needs of
our group were is certainly not something to your credit.
Your code will be placed in front of the scrutinizing eyes
of the Velocity developers just like everyone else. 
The simple fact is: just because
WM is out there and being used does not necessarily mean
it is better then Velocity.

> Otherwise I am setting back all my users, and my customers, and people
> like AltaVista, way back. JSP will snap up most of those people while
> we sit around trying to get back to where WM already is. 

What are you talking about? That is total uncomprehensible
nonsense!

How is "what" WebMacro is at this point time any different
then what it would be if Velocity wasn't here? It would be
exactly the same! How many of your core developers have
deserted you and joined us? And how many of your clients
are going to switch to Velocity at this point in time?
Probably none in the very near future. So you are
exactly where you would be anyway. That this has caused some
doubt in some of your users there is no question,
but that is for you to deal with. We offer your
users Velocity if they so choose to use it.

What exactly would you be doing differently right now
if Velocity wasn't announced. You would probably be
doing nothing different, that's what.

If you need immediate support for your clients, it's
not going to come from Velocity in a week.

I am planning to continue as I have. You have put
yourself in this unfortunate position. I make no
apologies for what I've done. I think in a
very short period of time we will have something
solid: the testbed, the benchmarks, and the
code prove it. 

jvz.

-- 

Jason van Zyl
[EMAIL PROTECTED]



------------------------------------------------------------
To subscribe:        [EMAIL PROTECTED]
To unsubscribe:      [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?:           [EMAIL PROTECTED]

Reply via email to