[storm] Moving Storm Forward

[Vernon Cole]

On Tue, Jun 9, 2009 at 9:46 AM, Gustavo Niemeyer <gustavo at niemeyer.net>wrote:

> Hi Vernon,
>
> > Storm seems to suffer from a Canonical-centric attitude. (If Canonical
> does
> > not need it, we're not interested.) This is almost never seen in other
> > Canonical projects like bazaar and launchpad.
>
> This is a quite unfair statement.  All of these projects, and even
> more noticeably with Launchpad and Bazaar, try *very* hard to adapt to
> the most common practices across software projects everywhere.  One of
> the known things about Bazaar is that it's able to handle many
> different kinds of workflows (people sometimes even criticize it
> exactly for that).
>
> Going back to Storm, one of the reasons you feel this way may well be
> my fault.  I've tried very hard since the beginning of the project to
> keep the scope under control.  Among other reasons, having a clearly
> defined and consistent base and making a good platform for building
> upon is more important than trying to handle all possible use cases.
>
> That said, this has nothing to do with Canonical vs. non-Canonical.
> We've rejected (with reasoning) requests coming from Canonical
> employees too.
>

Project scope is what worries me about my own hopes (or is it dreams?) for
Storm.

MS-SQL integration is being discussed here. Both of the existing MS-SQL
forks of Storm use adodbapi, which is gratifying to me since I have been the
maintainer of that package for the last few years. Unfortunately, adodbapi
uses a Microsoft COM interface, which will not work on Linux. (I suspect
that Canonical may be less than excited about such a dependency.) I have
searched in vain for a solid non-commercial platform to reach MS-SQL from a
Linux box. I actually got FreeTDS to work, but the syntax is so different
from adodbapi as to make a single-source program quite challenging if not
impossible. Perhaps Storm could do it, perhaps not.

My "best" solution so far is to:
  1) finish making Storm work on adodbapi on Windows
  2) make a fork of adodbapi which will run on ado.NET using IronPython.
  3) make Storm work on that platform
  4) port adodbapi to IronPython on Mono on Linux.
  5) make Storm work on that platform

I think you will agree that is a very large scope.

I hope that you will also see the potential of that scope. I personally
cannot see why any intellegent person would want to use either SQL Server,
or .NET, or IronPython, or Windows --  but there are millions of users (and
managers) out there who DO use them, and are under the false impression that
they are wonderful. If I want to sell (or even donate) a product in any
numbers, I must be able to use those platforms. I sold my Mac and got a PC
for the same reason. The Mac was better, but businesses kept buying MS-DOS
anyway.  If I want to sell application systems which will run on Ubuntu and
MySQL, which I do, I must also make them run on Windows and SQL Server.

In the future, will Storm communicate with the unwashed masses?  It requires
a huge committment. I no longer work for the company which forced me into my
use of SQL Server, When I left them, I got them to donate access to an old
MS-SQL machine so that I could continue to support adodbapi -- not because I
like it, but because it provides a migration path away from Redmond,
Washington.

>
> [ stuff cut out here...]
>
> Rest assured that there's no such things as a "keep-out" attitude from
> the Canonical team.  Most of us are long time open source developers
> which work in a very distributed way even when working for Canonical,
> and still participate in external projects.  Lack of time certainly
> limits our ability to do certain things, both internally and
> externally, but that's natural pretty much everywhere.
>
> --
> Gustavo Niemeyer
> http://niemeyer.net
>

Glad to hear it. I will be happy to learn that my pessimism is unwarranted.
--
Vernon Cole
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.ubuntu.com/archives/storm/attachments/20090609/d8287c18/attachment.htm