::scr Internet Explorer - Danger in numbers?

[Ash Argent-Katwala]

On Thu, 7 Mar 2002, Simon Wistow wrote:
>I've argued in the past that Opensource is Just Another Software
>Methodology [tm] that is utterly shite for any applications that aren't
>very simple.

Pretty much however you write stuff it'll break as it gets complicated,
until you build a better support for coping with the complexity. I would
question whether there is an open source method(ology). More that there are
various ways that open source development gets done at present, and there
will be others in future. That's as true for dev generally. It's fair to
bitch about how open source stuff gets developed now if you fancy - but it's
a separate line of argument to say /open-source/ can't be useful. To cut to
that you would have to attack things that are inherent to having the code
open. There are forky dangers, which are peculiar to open stuff, but they
can also be a strength (http://openacs.org/ & http://www.arsdigita.com/ ).

>But that's another argument. The upshot of this would be that
>OpenSourcde is, once again, a viable monopoly slayer. Especially since
>you could replace the closed bits of a monopoly one component at a time.

I think we still have a lot to do in seeing what is possible with tiny bits
of code. I'm convinced they are sufficiently potent for a lot of
purposes. It's still open whether the composition of a bunch of little tools
is any simpler though. At some level you can't win - the whole system has to
be sufficiently complex to get the job done.

As for switching out closed bits incrementally that's the kind of approach
that the OpenBeOS <http://www.openbeos.org/> folk are taking, and it is
compelling enough for me to not be bothering to install $another_os at home
for now. I can see how my morphed BeOS setup will satisfy what I need to do
for a while yet, while still delivering new, useful functionality. Without
the hope that they'll deliver some stuff over the next couple of years, I'd
jump ship.

>I've also frothed at the mouth many times about document centric
>interfaces - ones that have a document as the, err, center and then ave
>lots of small tools acting on them.

Have you played with Gobe Productive? It's quite a nice version of this. I
don't recall whether other people can whack other toolsets in, but it's
fairly one-documentish, and you can drop in a frame for this or that and get
the spreadsheet, image manipulation or whatever toolbar for the
subframe. Alas the Be version is getting fairly stale and they're shipping a
Windows version now. It's by the people who wrote ClarisWorks way back.

>The advantages being that you can use whatever small tool you happen
>like and they're very simple. 

Bingo, all the assorted helpers you get for editors are a fair shot at
this, they're often not much more sophisticated than piping some text
through something and out again. Or the freakishly niche modes for emacs.

>For the user it means that there's customisability with new components
>being easy to use. For the programmer it means that it's easy to program
>(because it's small), quick to prototype (because half the functionality
>will already be there) and, more importantly, for this discussion
>anyway, since it's small, it's easy to do a security audit.

Bingo. Of course the trouble with more layers is that someone might always
presume that the other is handling a certain case. You can't screen for
particular stuff if the next widget along is going to interpret things
differently (take the \r treated as newline in headers for Outlook lately, 
or 'begin' at the start of any line, in any context to get it to try and
uudecode stuff - it fairly thoroughly shags someone trying to screen
attachments earlier in the chain).

-- 
ash
a-k
... You have new mail (see above)