Re: [Mod-pubsub-developer] Re: Do commercial deployments count?

[Kragen S. <kra...@ai...>]

On Tue, Dec 16, 2003 at 12:47:51PM -0800, Joyce Park wrote:
> Thanks for the passionate response -- I was a bit worried at all the
> commonsensical "Just make nicer builds" responses, with no one really
> addressing my main point:  are we all cool with the choices we are making about
> the users we're targeting?

Oops, it wasn't intended to be passionate --- I'm sorry it came across
that way.

> > What is this about being tied to Apache?  The Python event router isn't
> > tied to Apache, and never has been.
> I agree that the Python server is not tied to Apache in a technical sense --
> but I think it should be in a marketing sense, at least for a browser-based
> package.  I thought we were all agreed on this, but evidently not -- so I guess
> the floor is open to discussion again.

I think advocating using it in conjunction with Apache is a good idea;
it's demonstrated its effectiveness by doing things like getting us
ApacheCon talks.  I thought you meant in a technical sense, and maybe
you were thinking about the Perl server as being central to mod_pubsub.

> > In the product we're deploying pubsub.py in, we have Apache, but as it
> > happens, Apache and pubsub.py never talk to each other.  (Yet.)
> 
> So this depends on your point of view, right?  You're thinking "Do I need to
> add Apache to the Python server for functionality reasons?" -- in which case
> the answer is "Obviously not".

Well, it's only obvious if you've actually installed it; that's why I
mentioned it, because I expect people who haven't yet installed an event
router will read the message.

> I submit that the average user (or at least the
> average in-the-browser user) is going to be thinking "How can I add this to my
> existing setup, which is Apache-based?" -- and therefore that is the real
> question we need to answer.  This is a point I was never able to get across at
> KN, and evidently am failing to get across in Mod-pubsub too:  people have
> existing shit, and we need to tell a story about fitting neatly into the
> interstices of their existing shit.  Where is the value in continuing to
> stubbornly insist "we are our own thing, we don't need no stinkin' web server"
> to a bunch of people who don't want or need to hear that?

I agree, and I think that kind of integration work is both very valuable
and usually surprisingly difficult.

> Look at PHP.  Are they technically superior to Python?  Evidently not.

Well, you know a little more about PHP than I do, having written the PHP
Bible, while I've never used it at all; but I have heard that some people
find it easier to do some things in PHP than in Python, for technical
reasons --- really good integration, specifically.  Do you think that
might be true?

> So how
> did they grow that huge community?  They targeted the huge mass of pre-existing
> Apache and IIS users as their market.  They did everything they could to make
> it easy to coordinate with Apache, and then with IIS.  They didn't have any
> qualms about categorically stating that PHP is a web-development language, even
> though it can do other things.  The PHP guys have focus and clarity in the
> problem they solve and the audience they're pitching to; while Python has taken
> the other tack of marketing themselves as a general-purpose programming
> language.  I respect the crap out of the Pythons, but I want Mod-pubsub to be
> PHP.  :-)

I don't know if I agree.  (Although I don't know if it matters, since I
haven't checked in any code lately, due to the aforementioned licensing
problems.)

I have heard that PHP has some disadvantages.  I've seen people complain
about difficulties structuring large programs, DWIM, Unicode, interface
stability, exception handling, and magic quotes (for non-PHP-users like
me, this is a unique PHP feature that automatically corrupts your data
before your program even reads it).

I think these problems may stem from the PHP team's intense focus on
ease of use for new programmers and simple applications.

So, for AirWave's product, an event router analogous to PHP might not
be ideal.  An event router that goes out of its way to paper over bugs,
automatically corrupts data, changes its interface every version, and
conflates separate namespaces, might make our product more expensive to
develop and maintain on top of it.  But we did sort of choose it because
it has PHP-like advantages, as discussed below.

But I understand that everybody's needs are different, 

> So the more I think about it, the more I think we are scaring newbie users off
> because of lack of focus.  There are just too many options, and we try to cover
> them all in one go -- we tend to babble something like, "We have two servers,
> one that's an Apache module and one that might or might not be run with Apache,
> and we have a gazillion clients in every programming language on every
> platform, and the whole thing can do everything and nothing!"  Not a very
> effective pitch, as amply demonstrated by our low conversion rate of interested
> people to active developers.

Yes, you're absolutely right.

> So my proposals are simple:
> 
> 1)  Divide the distro up into a webdev package, a Windows package, and an other
> programming languages package.  Nail the concerns of each audience.
> 2)  For the webdev package, target pre-existing Apache users as our audience.
> 3)  Agree on a strategy, so maybe we could make a statement about Mod-pubsub
> without a mass of qualifications attached.  This doesn't make us look flexible
> and precise -- it makes us look like we don't know what the heck we're doing.

I mostly agree.

The multiple servers are confusing, because people don't realize
they should just ignore the Perl one, even if they're using Apache.

The cross-language support is a real selling point, partly because it's
one of the best indicators of a project's maturity, and partly because
JavaScript is such a small part of the world: it has 1522 SourceForge
projects, compared to 12357 for C, 12212 for C++, 10623 for Java, 8048
for PHP, 5150 for Perl, 2851 for Python, and 1673 for Visual Basic,
all of which mod_pubsub supports.

Also, though, I think the jump from looking at the mod_pubsub blogchatter
app on the Web to trying to integrate the Python server with Apache is
too big.  The process for getting your Python server working with Apache
is a pain, and that pain should be postponed as much as possible when
somebody's trying out the system, even if they need to solve the problem
before they go into production.

Here's my outline of a better pitch:
- here, try out our <a href="">three example applications</a> on the web,
  then look at the source to see how simple building a new app is
- <a href="">here are thirty more if you want to see the full range of
  what we can do</a>
- you can <a href="">download this package</a>, unpack it, type
  "./pubsub.py" on your Linux box, then go to <a href="">this URL</a>
  to see the example apps running on your own machine; <a href="">here's
  a one-page tutorial on developing your own</a>
- if you're on Windows, you should run <a href="">this EXE file</a>
  instead (made with one of the Python EXE builders)
- you can serve your event-driven pages from an Apache server with <a
  href="">five easy steps</a>
- we also integrate with <a href="">ten other languages</a>, including
  Flash ActionScript, PHP, and Perl

I'd be happy to make the "download this package, unpack it, run this
command, and go to this URL" step use Apache if that's possible, but I
don't think it is, for the following reasons:
- many people who write web apps on Apache still don't install Apache
  on their desktop machines, even when those machines run Linux
- you have to convince Apache to serve some HTML files, and there's no
  safe way to do that except to tell the user, "figure out where to put
  these files so Apache will serve them."
- do the cross-domain stuff --- although we can probably do that before
  the download

AirWave chose mod_pubsub for our product because it appeared very easy to
integrate into our system (like, five lines of code to write simple apps
in Perl), because it looked relatively mature, due to the cross-language
support (despite my caution that we would be the first ones using it in
production) because it was relatively easy to get running so we could
try it out, because it was relatively simple --- unlike xmlBlaster ---
and because it seemed platform-compatible.  (i.e. we didn't have to
install and support Java, just Python.)

Hope this is helpful.