From: r coyne (duckingsnofair@yahoo.com)
Date: Mon Sep 22 2003 - 20:17:12 EDT
[If this belongs on the developer list, someone please
forward; I've never gotten acquainted with that one.]
Now that Abiword 2 is out, more or less (and people
are even speaking of 2.2), it's time to put in my two
cents worth on planning for Abi 3. Reading the posts
here, I am continually struck (and appalled, and
scared off) by how fragile abi is. One seems to need
exactly the right versions of everything, or they
won't work together and may cause very serious
problems. What with various projects and developers
and packagers and download sites all over the world
working rather independently and asynchronously, this
degree of coordination is not to be expected. And
even if it were possible, purely from the user's point
of view it is very inconvenient and offputting to have
to upgrade everything at once rather than
incrementally at leisure and maybe selectively. And
what gets me is that I don't see why it has to be this
way.
Take plug-ins, for example -- a never-ending source of
problems. I don't understand how plugins work, but
surely it should be possible to vector them through
some sort of table of pointers or jump addresses or
instructions in such a way that any given
function(ality) is guaranteed to be findable in the
same place even as the actual code gets rewritten and
moved around and new abilities added in future
versions.
I realize that abi is designed to run on a multitude
of platforms and that this complicates matters. But
don't all operating systems nowadays provide pretty
much the same basics, like a directory tree,
environmental variables, pipes, and so on? And if you
stick with a programming language compiler/package
that is widely available, won't it do a lot of the
work of coordination, adapting to each OS it runs on?
So if you take a lowest-common-denominator approach
and if you spend enough time and effort early on, like
now, working out the conventions for how the various
routines, modules, files, programs, plugins, packages,
etc. are supposed to find and communicate with each
other, I would think you could come up with something
less demanding and more robust than the present
arrangements.
And to the extent this requires discussions and
agreements with other projects, get to it; attend
those conferences. If somebody in the open-source
world has to invent some conventions, why not abi?
Design something that will do the trick and put out a
RFC.
And then, of course, there's the whole issue of
intelligent, informative, crash-proof handling of
error conditions, and the need for careful, loving
attention to documentation.
What I am saying, basically, is that with the release
of 2.0, abi is probably approaching the point of
diminishing returns to features. 3.0 should be about
bulletproofing and getting it "ready for prime time";
in other words, this is the time to "start over from
the beginning and this time do it right," now that you
understand the problems.
But then, I haven't programmed in years and am far
from au courant, so I'm just talking through my hat
and may be totally wrong. And I do mean this as a
what-the-user-wants tip for 3.0, not a criticism of 1
and 2 or the developers who gave them to us. In the
early versions, it was only natural and proper to
concentrate on getting something up and running that
would be worth using. I write this because I suspect
that, especially in a decentralized, volunteer
organization like abi, with no one exactly in charge
and authorized to turn the whole thing on a dime,
institutional habit and momentum may inhibit the sort
of grand rethinking I'm talking about, even when it is needed.
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
-----------------------------------------------
To unsubscribe from this list, send a message to
abiword-user-request@abisource.com with the word
unsubscribe in the message body.
This archive was generated by hypermail 2.1.4 : Mon Sep 22 2003 - 20:31:43 EDT