Re: [9fans] mothra

Re: [9fans] mothra

[Randolph Fritz]

A few thoughts:

  It occurs to me that the "grail" browser, written mostly in Python and
  incomplete, might be a good candidate for Plan 9 usage.  Maybe...

  There was also, in the acme paper I read, a brief mention of making
  acme display other data types than plain text.  Did anything ever come
  of that?

-- 
Randolph Fritz
Eugene, Oregon, USA

Re: [9fans] Re: we need help...

[matt]

there's not *that* much wrong with mothra.
The aforementioned cookies, and I'd like to be able snarf text too.

One thing I've often wanted to put together was a web browser that browsed the HTML but with live links

I've not really looked at the mothra source despite being interested in doing so.

m

[9fans] mothra

[Richard Miller]

 From the Flogging a Dead Horse department:

By popular request (of matt@proweb.co.uk) mothra will now accept
and send cookies if /mnt/webcookies is accessible when mothra starts.
It will also now listen on plumbing channel "web" for URLs to fetch.

I've also fixed a few memory-corruption errors which should make
it somewhat more stable.

New version is in /contrib/mothra on sources.

It still doesn't handle tables, scripts, stylesheets, etc etc etc.

-- Richard

Re: [9fans] mothra

[rob pike]

>  There was also, in the acme paper I read, a brief mention of making
>  acme display other data types than plain text.  Did anything ever come
>  of that?

Beyond some early experiments, no.  It's still on my list.

-rob

Réf. : Re: [9fans] mothra

[boyd.roberts]

    The next real hard part is getting the layout (especially tables!)

sed | tbl | troff

you see the way i'm thinking?

[9fans] Re: Réf. : Re: [9fans] mothra

[Howard Trickey]

> sed | tbl | troff
> 
> you see the way i'm thinking?

Yes..  Now how do you draw a line from
the end of the troff pipe back into tbl in
your diagram?  You need the full power
of the layout engine available to the table
processer, as sizing depends on the layout
of nested tables in a very insidious way.
and the real fun begins when a cell is allocated
a certain width, and the contents don't fit.
Or when the various width and pad specs
of the whole nested set of tables are
impossible to satisfy simultaneously.
Then you have to "give up" in exactly the
same way as Netscape and IE...
(I seem to have the phrase burned on
my brain, don't I?)
And then try to handle images of unknown
size arriving later, and try to minimize the
number of unnecessary trial layouts.

Most of my layout bugs were due to
tables.

- the fool

[9fans] Re: [9fans] Re: Réf. : Re: [9fans] mothra

[Lucio De Re]

On Wed, Jul 19, 2000 at 08:31:09AM -0400, Howard Trickey wrote:
> 
> Yes..  Now how do you draw a line from
> the end of the troff pipe back into tbl in
> your diagram?  You need the full power
> of the layout engine available to the table
> processer, as sizing depends on the layout
> of nested tables in a very insidious way.

That seems unavoidable.  And you've been there, I haven't :-)  But it
strikes me as a recursive descent problem that should really have only
one solution, or, at worst, scroll bars :-)

> and the real fun begins when a cell is allocated
> a certain width, and the contents don't fit.
> Or when the various width and pad specs
> of the whole nested set of tables are
> impossible to satisfy simultaneously.

Perhaps some scaling knobs in the right places...

> Then you have to "give up" in exactly the
> same way as Netscape and IE...
> (I seem to have the phrase burned on
> my brain, don't I?)

... rather than rely on previous foolishness :-)

> And then try to handle images of unknown
> size arriving later, and try to minimize the
> number of unnecessary trial layouts.
> 
Except for the need to match prior art (which I understand and hope to
be right in disregarding) I believe we can solve all these problems,
if for no other reason that typography is not a recent invention.  If
we aim at elegance rather than "accuracy" (intentional scare quotes),
and we make the product readily available, we may just swing enough
decision makers to make a difference.

If lynx wasn't so hideously ugly, I believe it would have made its
mark in this sense too.

> Most of my layout bugs were due to
> tables.
> 
How many were actual errors, versus mere divergence from a crooked de
facto standard?

> - the fool
> 
Your experience is undoubtably invaluable.

++L

Re: [9fans] mothra

[Colin DeVilbiss]

> If lynx wasn't so hideously ugly, I believe it would have made its
> mark in this sense too.

c.f. w3m, a unix curses-based web browser with pretty good table
rendering, and one which can render frames by making them look like
tables.

http://ei5nazha.yz.yamagata-u.ac.jp/~aito/w3m/eng/

speaking from experience, it's good enough for me, but, being tied to
cursor-addressability, isn:t a candidate for a direct port by any means.

-- 
Colin DeVilbiss
crdevilb@mtu.edu

Re: [9fans] mothra

[Russ Cox]

i agree with skip

 From cse.psu.edu!owner-9fans Wed Apr  8 00:45:34 EDT 1998
From: "Fariborz "Skip" Tavakkolian" <prognet.com!skipt>
Subject: Re: [9fans] netscape

Isn't porting Netscape to Plan9 one of the signs of Armageddon?

Re: [9fans] mothra

[forsyth]

> Hopefully not.  Maybe Opera, but does one really need Netscape's
> near-operating system effort just to present a few pictures?
> 
>>Perhaps the way to approach it is to make Mozilla into a Plan 9
>>terminal. :)  (Only joking.  I think.)

Possibly.

Chris Locke wrote an Inferno plug-in for Internet Explorer that lets
you run a full Inferno session (including window manager, charon and Acme)
in an explorer page.  Inferno is running in the page, it's not just
a terminal, although it can obviously then mount remote services.

Re: [9fans] mothra

[Randolph Fritz]

On Tue, Jul 18, 2000 at 07:26:22PM +0000, forsyth@vitanuova.com wrote:
> 
> Chris Locke wrote an Inferno plug-in for Internet Explorer that lets
> you run a full Inferno session (including window manager, charon and Acme)
> in an explorer page.  Inferno is running in the page, it's not just
> a terminal, although it can obviously then mount remote services.
>

The words of the apocalypse:

  It would be perfectly practical to implement 9P as a Javascript
  class.  The rest, as they say, is left as an exercise to the
  student.

Randolph, wondering if he's created a monster

Re: [9fans] mothra

[Chris Locke]

Randolph Fritz <randolph@cyber-dyne.com> wrote in message
>
>   It would be perfectly practical to implement 9P as a Javascript
>   class.

You are confusing Java and Javascript.
They share 4 letters of their name and that's about all.
Chris.

Re: [9fans] mothra

[Andy Newman]

Chris Locke wrote:
>You are confusing Java and Javascript.
>They share 4 letters of their name and that's about all.

Oh come on. The operator lexicon is almost identical!

-- 
Chuck Berry lied about the promised land

Re: [9fans] mothra

[miller]

If anyone is nostalgic for mothra itself, I've just about finished
adapting it (and the panel library, which I needed for my teletext
browser) to the 3rd edition graphics model.  Mothra may only be able
to cope with a small subset of today's websites, but for that subset
it's quick and effective. (I've borrowed from lynx the idea of displaying
frames as a list of links, so that framed sites can be navigated
without having to lay them out fully.)  Because it ignores what it
doesn't understand, mothra can often glean some useful content from a
page where charon tries too hard and just draws a blank.  And using
mothra I don't have to worry about malicious scripts and cookies ...

Anyone with a 2nd edition license can get a boddle from me.

-- Richard Miller

Re: [9fans] mothra

[Steve Kilbane]

It seems to me that the reason why a web browser would be such a
behemoth is because current browsers try to do everything in one.
Breaking the problems down might produce something that's more
reasonable.

The protocols should be separate. Whether it's something as
simple as writing a URL to a ctl file and reading a page back
from a data file, or something more subtle, I don't know, but
the posting and fetching shouldn't have much of a clue about
what to do with the result.

Since the spec keeps changing, maybe the returned page could be
translated into a local language that was more stable, and more
attuned to using a filesystem as the underlying namespace model
than URLs.

For doing the translation, perhaps a leaf could be
taken from troff's book, and have subcomponents of the page
translated into something else - the underlying, internal
language.

There's always going to be some sites (or parts of them) that
fall through the gap and don't work. But that's true now, for
everyone...

steve

Re: [9fans] mothra

[Chris Locke]

Steve Kilbane <steve@whitecrow.demon.co.uk> wrote in message
news:200007181831.TAA12571@whitecrow.demon.co.uk...
> It seems to me that the reason why a web browser would be such a
> behemoth is because current browsers try to do everything in one.
> Breaking the problems down might produce something that's more
> reasonable.
>

Charon is indeed implemented in a fairly 'modular' way
by virtue of it being written in Limbo.

There are 'protocol' modules for the http, ftp and file URL protocol
specifiers. URL parsing is done by a distinct module.
Image cache, again a separate module.
Ecmascript - separate module, carefully designed for re-use in
any app that wants ECMA-262 support.

What you find is that you have to implement a huge amount of
stuff that, even though carefully crafted as distinct modules,
only the browser actually uses!

Having worked with web-phone manufacturers, the modular nature of
Charon is great as you can simply not include certain
modules (e.g. Javascript) on a phone to free up some flash.
But in reality everyone wants everything.
Worse, they want it to look exactly the same as IE, including
quicktime, windows media player, macromedia flash vector
graphics etc etc and they complain when it doesn't
run in under 4MB on a device with no hard disk!

If you start on a web-browser project, be under no illusion as
to how much people will moan about your efforts, even if they were
never meant to be 'the latest and greatest web browsing experience'.
There will always be a page that someone wants to see that your
software doesn't render and you can bet you'll hear about it!

Throwing a few more irons in this fire - consider the number of sites
that use Javascript for simple navigation, redirection
and stuff like that.  It is impossible to get some pages
without Javascript support.
You just need a URL you say? PAH I say! URLs get generated by
servers on the fly, parameterised to indicate some notion
of 'session' (trying to get round failing of the underlying
protocol) - how's that going to work in a Fileserver model
for web access?

Just my 2p's worth
Chris.

(Posting from home - my views not Vita Nuova's)

Re: [9fans] mothra

[Lyndon Nerenberg]

>>>>> "Steve" == Steve Kilbane <steve@whitecrow.demon.co.uk> writes:

    Steve> The protocols should be separate. Whether it's something as
    Steve> simple as writing a URL to a ctl file and reading a page
    Steve> back from a data file, or something more subtle, I don't
    Steve> know, but the posting and fetching shouldn't have much of a
    Steve> clue about what to do with the result.

Exactly. An httpfs that just serves HTTP raw MIME content (and handles
caching).

We have to divorce HTTP from HTML. They're two distinct problems.

We should look at the 3rd edition mail system for clues on how
to layer an HTML reader on top of an HTTP fileserver. The mail
problem is very similar: MIME on top of IMAP. s/IMAP/HTTP/ using
the existing MUA tools and we're much of the way there. (Especially
if httpfs can export a file/directory structure comparable to how
the IMAP server does it. httpfs caching might in fact be mandatory
for this to be possible.)

--lyndon

Re: [9fans] mothra

[Howard Trickey]

> Exactly. An httpfs that just serves HTTP raw MIME content (and handles
> caching).
>
> We have to divorce HTTP from HTML. They're two distinct problems.

You're kidding yourself if you think this comes anywhere near solving
the big problems in writing a web browser.  Actually fetching the bits
and passing them along is trivial.  (And, in any case, fetching the bits
is more closely tied to the logic of the browser than you might think:
you have to deal with redirections, errors, and authorization requests.
And, it is good to be able to start rendering before all of the HTML
has arrived, and certainly before all of the images have arrived.)

I wrote the first version of the charon browser with a "webget" filesystem
to serve the pages.  I abandoned it in later rewrites, mainly for speed
reasons, but also because it wasn't buying me anything.  We only ever
had one web client attached to the damn thing anyway.  But that could
change in a Plan 9 environment...

Separating things into pieces is easy, but doesn't help much if the pieces
are hard.

The first real hard part is lexing/parsing the html in a way that is
forgiving
of errors in exactly the same ways as Netscape and IE. The next real hard
part
is getting the layout (especially tables!) exactly the same as Netscape and
IE.
Another hard part is SSL, just because ASN1 is a pain in the butt.
The hardest hard part is making Javascript objects and methods that behave
exactly the same as Netscape and IE (especially if you want to do something
different with respect to the concepts of "top level windows" or "frames").

And don't say "it doesn't have to be exactly the same as Netscape and IE"
until you've had users.

- Howard Trickey, erstwhile fool

Re: [9fans] mothra

[Lucio De Re]

On Wed, Jul 19, 2000 at 07:45:36AM -0400, Howard Trickey wrote:
> 
> You're kidding yourself if you think this comes anywhere near solving
> the big problems in writing a web browser.  Actually fetching the bits
> and passing them along is trivial.  (And, in any case, fetching the bits
> is more closely tied to the logic of the browser than you might think:
> you have to deal with redirections, errors, and authorization requests.
> And, it is good to be able to start rendering before all of the HTML
> has arrived, and certainly before all of the images have arrived.)
> 
I'm sure Howard is as good a judge of difficulty here as any.  But
there is one key issue that we are a little luckier with: we do not
have "clients" to satisfy.  We _need_ a browser for mundane
operations, but we are not dependent on it, nor are we _here_ hellbent
on having our pages delivered exactly like Netscape of IE5.

> I wrote the first version of the charon browser with a "webget" filesystem
> to serve the pages.  I abandoned it in later rewrites, mainly for speed
> reasons, but also because it wasn't buying me anything.  We only ever
> had one web client attached to the damn thing anyway.  But that could
> change in a Plan 9 environment...
> 
I keep thinking SQUID here.  Squid does a hell of a lot of useful
work, without having the foggiest idea what it's about.  Webget,
presumably, was along the same lines.

> The first real hard part is lexing/parsing the html in a way that is
> forgiving
> of errors in exactly the same ways as Netscape and IE. The next real hard
> part
> is getting the layout (especially tables!) exactly the same as Netscape and
> IE.

html2ps gets this bit done well enough to be a useful tool.  _I_ have
little to complain about that.  Again, the audience isn't a commercial
buyer.

> Another hard part is SSL, just because ASN1 is a pain in the butt.

No, that can't be hard.  Tedious, certainly, but useful.

> The hardest hard part is making Javascript objects and methods that behave
> exactly the same as Netscape and IE (especially if you want to do something
> different with respect to the concepts of "top level windows" or "frames").
> 
This, and Java, naturally, are bugbears.  But we can perhaps refine
these as conditions demand.  The possibility of adding plug-ins seems
the only useful route.  Perhaps that is particularly hard, but not yet
daunting.

> And don't say "it doesn't have to be exactly the same as Netscape and IE"
> until you've had users.
> 
You made me say it.  We have users, but not clients.  Often, all
I want is a single page, preferably stripped of images and banner
adverts.  What I do think is invaluable is a protocol that interacts
more intelligently with the proxy server.

++L

PS:  another point worth making is that IE-5 is far trimmer than
Netscape.  Netscape carries far too much baggage, even Navigator.  I
have little idea how this is reflected in Mozilla.

Re: [9fans] mothra

[Steve Kilbane]

> You're kidding yourself if you think this comes anywhere near solving
> the big problems in writing a web browser.

I think we're looking at different problems.

To me, Plan 9 has always been about stepping back, looking at the
whole problem, and solving it with hindsight. Nods to the outside
world are at the borders between Plan 9 and reality. Within the
bounds of the system, compatibility with less discerning environments
is not an issue.

Is a web browser an exception? Maybe. Maybe not.

On the one hand, the point of the WWW is the first two WWs. On the
other hand, I'm sure there aren't that many people who can view
every site they visit with impunity.

So Plan 9 could only hope to reach a fraction of the sites. 10% of
the work might get you 90% of the sites, to a bearable degree. If they're
the 90% you want, it might be good enough to save you a reboot.

So I'm wondering if you take what the web has to offer - what people
try to show, in pages - and revisit it, from a Plan 9 viewpoint. Build
a Plan 9-only internal system, and translate at the boundary.



> The first real hard part is lexing/parsing the html in a way that is
> forgiving
> of errors in exactly the same ways as Netscape and IE.

I'm not that concerned. If I can work out what the content is supposed
to be, that'll do. "Exactly the same" is not an issue.

> The next real hard part
> is getting the layout (especially tables!)

But I'd hope that the internal system wouldn't use HTML (or at least,
not the outside version), but something else, more regular and predictable.
The table processing would be a single component of the translator.

> The hardest hard part is making Javascript objects and methods that behave
> exactly the same as Netscape and IE (especially if you want to do something
> different with respect to the concepts of "top level windows" or "frames").

Thoroughly unpleasant, yes. I'd be more inclined to live with frames (as
a supported concept at the translator) and dump javascript, though.

> And don't say "it doesn't have to be exactly the same as Netscape and IE"
> until you've had users.

But that all depends on the users, doesn't it? I've routinely got Java*
turned off. I don't have Flash, Shockwave, IE, Real* players, or any of
that rubbish. Personally, I get by without those sites. Others may not
be happy with that; they know where the solution lies. The same is true
for people who like MS Office, emacs, X, etc.

Perhaps this is being overly parochial. Everyone uses the Netscape and IE
features we know and loathe.

Everyone uses TCP, too. Plan 9 has IL.

steve

Re: [9fans] mothra

[Boyd Roberts]

Steve Kilbane wrote:

> To me, Plan 9 has always been about stepping back, looking at the
> whole problem, and solving it with hindsight.
the stuff that came out of the unix room always struck me as
distilling it down to the essense;  doing more with less.
i don't think i've ever seen that anywhere else (well,
maybe PARC, but that's a bit before my time).

--
Boyd Roberts                            boyd@psycho-basket-case.org

     ``I come over here to kill them cocksuckers, not work for 'em''

           -- Moon Dog, _Pettibone's Law_, John Keene

Re: [9fans] mothra

[Lyndon Nerenberg]

>>>>> "Howard" == Howard Trickey <howard@research.bell-labs.com> writes:

    Howard> Separating things into pieces is easy, but doesn't help
    Howard> much if the pieces are hard.

I'm surprised to hear you say that. IMO modularization is something
you want when dealing with complex programming tasks. At the very
least it simplifies the verification process for the functional
components.

    Howard> And don't say "it doesn't have to be exactly the same as
    Howard> Netscape and IE" until you've had users.

I spent a year developing our webmail product, and have more experience
in this regard than I ever want to be inflicted with again. I'm not
interested in reimplementing IE or Netscape. If I need those products,
they are available to me elsewhere. What I am interested in is seeing
how I can take advantage of Plan9 to create a (possibly new) method of
viewing the web. I'm not interested in Java(script), Macromedia Flash,
or any of the other Whizzo Butter(tm) gizmos. My life is no less
complete for the lack of being able to view web pages that require that
sort of support. I haven't enabled Java(script) in any of my web
browsers for a couple of years now. (Well, except for when I was
doing webmail development. They're never enabled when I'm doing
general browsing, and I never use webmail as a consumer.)

--lyndon

Re: [9fans] mothra

[Tom Ivar Helbekkmo]

Lyndon Nerenberg <lyndon@messagingdirect.com> writes:

> I'm not interested in reimplementing IE or Netscape. If I need those
> products, they are available to me elsewhere. What I am interested
> in is seeing how I can take advantage of Plan9 to create a (possibly
> new) method of viewing the web.

Hear!  Hear!  If one wants Netscape or IE, they're available.  If one
wants a tool that's geared toward the distributed sharing of
information in the context of a useful structure, something new and
interesting is needed.  The current XML trend is not it.  SGML is
closer (and actually is what XML merely claims to be), but it has its
flaws, and does not appeal to anyone who hasn't already figured out
that they need it.  A new flavor of web browser, in the spirit of Plan
9, might be a very good vehicle for the investigation of alternative
ways of disseminating information.

-tih
-- 
The basic difference is this: hackers build things, crackers break them.
                                                     --Eric S. Raymond

Re: [9fans] mothra

[Andy Newman]

Steve Kilbane wrote:
>For doing the translation, perhaps a leaf could be
>taken from troff's book, and have subcomponents of the page
>translated into something else - the underlying, internal
>language.

They are - boxes.  CSS2 defines a layout mechanism based on
boxes with different layout characteristics.  A modern browser,
e.g, Mozilla, maintains and transforms trees which eventually
get processed to draw something.  The document is a tree - HTML
or XML or something, there is a frame representation (the boxes).
Frame generation is controlled by style sheets which also specify
other attributes of the presentation. Frames are then processed
by the layout machinery to generate actual presenation commands.
There are numerous types of frames and numerous rules for how
they combine when positioned on some surface. Also remember that
HTML specifies interactive elements (and most sites use them)
and there's tables thrown in for good measure and they have their
own particular needs. JavaScript these days is for manipulating
the trees, i.e, dynamic HTML, where they CSS attributes get changed
in response to some event. Anyone who's done a page layout program
or formatter of any kind will appreciate the complexity of handling
modern HTML.  If you ignore style sheets it isn't too bad. The modern
rules make it harder. At least it gives the processors and memory
manufacturers cause for celebration.  Can't wait for a fully XML
enabled watch, probably generate enough heat to keep my wrist warm.

Re: [9fans] mothra

[rob pike]

> > I'd rather see web access be one aspect of a system in
> > which the pieces work in concert.

> Isn't that what caused Microsoft some trouble?

No.

-rob

Re: [9fans] mothra

[Sape Mullender]

Rob writes:
> I'd rather see web access be one aspect of a system in
> which the pieces work in concert.

Isn't that what caused Microsoft some trouble?

	Sape

Re: [9fans] mothra

[Holger Veit]

On Tue, 18 Jul 2000 14:05:02 GMT,
	Sape Mullender <sape@plan9.bell-labs.com> wrote:
>Rob writes:
>> I'd rather see web access be one aspect of a system in
>> which the pieces work in concert.
>
>Isn't that what caused Microsoft some trouble?

Probably yes, but then mainly because they didn't/don't have a concept.
You don't get a system if you throw together some arbitrary components
that may or may not communicate.

Holger

-- 
Zur Signatur: http://www.detebe.org/3.14/ILOVEYOU-Signature-FAQ.html
begin  LOVE-LETTER-FOR-YOU.txt.vbs
Wirf' diesen Schrott von Mailprogramm weg, der hier ein Virus vermutet!
end

Re: [9fans] mothra

[rob pike]

> I have a vague feeling that this can be mapped onto a filesystem, or am
> I dreaming?

It has to be done very very carefully because URLs are not a naming
system.  C.f. the discussion earlier on this topic, I argue for a model
more like /net than ftpfs.  We've started explorations in that direction,
but it's too early to tell if we'll get anywhere useful.

-rob

Re: [9fans] mothra

[Lucio De Re]

On Tue, Jul 18, 2000 at 08:51:26AM -0400, rob pike wrote:
> 
> > I have a vague feeling that this can be mapped onto a filesystem, or am
> > I dreaming?
> 
> It has to be done very very carefully because URLs are not a naming
> system.  C.f. the discussion earlier on this topic, I argue for a model
> more like /net than ftpfs.  We've started explorations in that direction,
> but it's too early to tell if we'll get anywhere useful.
> 
Accepted that URIs are an abomination :-) but consider "html2ps",
misguided Perl script that it is.  Within its own limits, it is quite
capable.  If one draws the line at locally available information for
the presentation (the rendering engine), the actual information
retrieval may just have to be less canonical.

Treating the two problems as one is likely to lead to desperation, but
perhaps by attempting to decouple them, they may become more
tractable.

You already have a perfectly good uget/hget, which I thought would
make a fine replacement for the DHCP client, anyway - why have a
plethora of protocols to retrieve an arbitrary set of key=value
entries?  Why not use HTTP?

But ignoring that sidetracking, I think a rendering tool that relies
on hget for the data input and something similarly simple for form
filling purposes, ought to be within human abilities.

Keep in mind that I, at least, believe that the web browser is quite a
versatile tool, and it is hard to imagine a computing resource of any
value that does not include such a tool.  In fact, imagine having to
live without it for any length of time at this point.

That said, perhaps more of us should approach Opera and request a
port.  I am surprised they did not respond, perhaps you forgot to
highlight quite who you were?  A bit like David Korn and the famed
Microsoft press release of their Windows tools for Unix?

I'll try and do some needling, the Opera people seem to have completed
their port to BeOS and whatever else, although not to Linux, unless
I've missed their annoucement, they may have resources to spare.

I must say I respect their persistence in the face of enormous
competitive pressure.

++L

Re: [9fans] mothra

[rob pike]

> Hopefully not.  Maybe Opera, but does one really need Netscape's
> near-operating system effort just to present a few pictures?

Opera is indeed a better idea.  I tried to engage them about doing
a port to Plan 9 but didn't even receive the courtesy of a reply.

-rob

Re: [9fans] mothra

[rob pike]

> Surely somebody must be trying to port Mozilla to Plan 9?

While that would be better than no browser at all, Mozilla is
just the sort of stand-alone monolith that we're trying to
argue against. And of course, everyone else in the world is
trying to turn their system into a giant web browser. I'd rather
see web access be one aspect of a system in which the pieces
work in concert.

-rob

Re: [9fans] mothra

[Douglas A. Gwyn]

rob pike wrote:
> While that would be better than no browser at all, Mozilla is
> just the sort of stand-alone monolith that we're trying to
> argue against. And of course, everyone else in the world is
> trying to turn their system into a giant web browser. I'd rather
> see web access be one aspect of a system in which the pieces
> work in concert.

That would be nice, but meanwhile life without a Web browser is
nearly impossible..

[9fans] mothra

[boyd.roberts]

how come mothra bit the dust?

Re: [9fans] mothra

[Tom Duff]

> how come mothra bit the dust?
I wrote it.  It was not in good condition when I left
Bell Labs.  Understantably, nobody else wanted anything
to do with it, so it died.

Its biggest shortcoming (other than its general
internal hidousness) was that its document imaging
model was fixed before <table> entered the picture.
Deep down it believed that documents were running text
with embedded line-breaks and indent changes, meaning
there's no good way to get tables or frames to work.

Also, if your browser doesn't closely match Netscape
and Microsoft, people will believe that it just doesn't
work, regardless of how good a job you do of meeting the
published specifications.

On the other hand, I still think its idea of how to handle
navigation (mostly the panel with an LRU list of pages visited)
was better than anything else I've seen.

Writing a web browser is a fool's errand.  The specification
was changing faster than I could type, and still is.

-- 
Tom Duff.  Just a minute, I think I've got one in the car.

Re: [9fans] mothra

[Howard Trickey]

Tom Duff wrote:
> Writing a web browser is a fool's errand.  The specification
> was changing faster than I could type, and still is.

Don't I know it!

- Howard Trickey, erstwhile fool

Re: [9fans] mothra

[Michael Jeffrey]

we hope to start shipping Plan 9 CDs very soon.  The
CD will include an emulated version of Inferno which
will in turn include Charon the Inferno browser.
Apparently the fools errand has been passed on to us -
we'll see what we can make of it.

Michael Jeffrey

Re: [9fans] mothra

[Douglas A. Gwyn]

Surely somebody must be trying to port Mozilla to Plan 9?

Re: [9fans] mothra

[Lucio De Re]

On Tue, Jul 18, 2000 at 08:25:22AM +0000, Douglas A. Gwyn wrote:
> 
> Surely somebody must be trying to port Mozilla to Plan 9?

Hopefully not.  Maybe Opera, but does one really need Netscape's
near-operating system effort just to present a few pictures?

I think we may want to reverse the paradigm: when we were considering
http options, it was established that the filesystem representation
would fall short of needs.  But perhaps a graphic model can be
designed with HTML as its input, and one may even make it flexible
enough to deal with revamps such as the addition of tables and frames.

I have a vague feeling that this can be mapped onto a filesystem, or am
I dreaming?

++L

Re: [9fans] mothra

[Wladimir Mutel]

Lucio De Re <lucio@proxima.alt.za> wrote:
> On Tue, Jul 18, 2000 at 08:25:22AM +0000, Douglas A. Gwyn wrote:
>> 
>> Surely somebody must be trying to port Mozilla to Plan 9?

> Hopefully not.  Maybe Opera, but does one really need Netscape's
> near-operating system effort just to present a few pictures?

	Gecko rendering engine is small and almost suitable for embedding,
	they said. Near-OSness of Mozilla5/Netscape6 is just a result of
	poor decomposition. But it seems 'Gecko' itself could be adopted
	under Plan9. To be something like 'page' but for viewing html.

--
mwg@alkar.net, 340044, 7442333, 7786458 - Владимир Мутель

Re: [9fans] mothra

[Lucio De Re]

On Tue, Jul 18, 2000 at 10:48:38AM +0000, Wladimir Mutel wrote:
> 
> 	Gecko rendering engine is small and almost suitable for embedding,
> 	they said. Near-OSness of Mozilla5/Netscape6 is just a result of
> 	poor decomposition. But it seems 'Gecko' itself could be adopted
> 	under Plan9. To be something like 'page' but for viewing html.
> 
I've been wondering about rendering engines across the board: a lot
of Linux's appeal lies with the availability of games, and I see
little reason, with Tom Duff and Rob Pike's experience and skills
(talents, really) why Plan 9 could not provide similar tools.

Of course, my personal wish list is more or less infinite :-)

Is a URL for gecko readily available?

++L

Re: [9fans] mothra

[Wladimir Mutel]

Lucio De Re <lucio@proxima.alt.za> wrote:

>> 	Gecko rendering engine is small and almost suitable for embedding,

> Is a URL for gecko readily available?

	http://www.mozilla.org/ - get the source
	It should be in Mozilla source, I guess.

--
mwg@alkar.net, 340044, 7442333, 7786458 - Владимир Мутель

Re: [9fans] mothra

[Andy Newman]

Wladimir Mutel wrote:
>	Gecko rendering engine is small and almost suitable for embedding,
>	they said. 

They lied.

Re: [9fans] mothra

[Randolph Fritz]

On Tue, Jul 18, 2000 at 10:58:38AM +0200, Lucio De Re wrote:
> On Tue, Jul 18, 2000 at 08:25:22AM +0000, Douglas A. Gwyn wrote:
> > 
> > Surely somebody must be trying to port Mozilla to Plan 9?
> 
> Hopefully not.  Maybe Opera, but does one really need Netscape's
> near-operating system effort just to present a few pictures?
> 

Perhaps the way to approach it is to make Mozilla into a Plan 9
terminal. :)  (Only joking.  I think.)

-- 
Randolph Fritz
Eugene, Oregon, USA

Re: [9fans] mothra

[Douglas A. Gwyn]

Lucio De Re wrote:
> Hopefully not.  Maybe Opera, but does one really need Netscape's
> near-operating system effort just to present a few pictures?

Who said "just to present a few pictures"?
These days, any Web browser appreciably less functional than
Netscape 4.0 is simply unusable with many Web sites.
That might be regrettable, but it's the way things have evolved.