Re: Will Monolithic Apps Dominate?

[Unprivileged user <nobody@www.video-collage.com>]

On Fri, 18 Jul 1997, Tim May wrote:

> I'm not at all convinced that monolithic apps like this will do well. A
> cluster of smaller apps, provided they have relatively consistent
> look-and-feel, as they mostly do, will probably do better for many of us.
> Smaller, nimbler apps are harder for government forces to regulate,
> influence, and limit.
> 
> What does this mean for crypto, certificates, etc.? It means that what
> Netscape, Microsoft, and other monolithic app suppliers don't hold all the
> cards. What the government forces/cajoles NS and MS to do with
> certificates, crypto, Web ratings, could end up helping more users decide
> to defect from the monolithic apps to smaller,less constraining apps.

It has been called bloatware and it affects everything.  Consider PGP 5.0.
As far as I know, all the technology being scanned in over this month is
available outside the US (e.g. SSLeay, and zip).  Although I would rather
have multiple implementations, SSLeay is a DLL under windows, but now I am
also going to have a PGP50 DLL, both with MPI and crypto libraries.  And
that doesn't count the same functions which are in both netscape and msie.

Both Netscape and MSIE could have taken an approach where the crypto was
put in a different app (i.e. safepassage), so the SSLproxy app would only
be available in the US, and cloned at full strength elsewhere.  You can do
something equivalent on the server side (443 -> SSL-to-plain -> 80).

Unless I am really doing something graphic based, I use Lynx.  Or "geturl
http://whatever | tablerender | less".

What is worse about MS/NS is that they can't be automated.  I can do a
croned geturl every 5 minutes, but how do I extract a given table from a
site and import it into excel automatically?  I think excel will
eventually support URLs in some fashion if it doesn't already, but there
are more things which won't parse as easily.  And what if the data is on
the other side of a form?

I think part, if not most of the problem is the GUI paradigm.  It is very
expensive to start another app, so people clamor for features to be built
in to existing apps, so every app must do things other apps do.  If you
can't click on it, you can't do it.  If there is no Download and save the
Nth GIF on this page every 5 minutes, I won't be able to do this with a
normal browser.

This is in contrast to the CLI-filter-pipe paradigm where every program
just does one thing.  That thing can be extremely flexible (e.g. awk), but
it has a limited scope, and another app does other things, but they are
designed to be chainable.  But it requires thinking to build these chains
and "average" users refuse to learn how.  geturl www.wherever | grep
"pic.gif" | awk ... >nextfile.get; geturl `cat nextfile.get` >`date ..`
as a cron job will do the function I suggested above.

The question is how to merge the two so GUI apps are small and chainable
(maybe embeddable?).

--- reply to tzeruch - at - ceddec - dot - com ---