[9fans] Gecko based web browser

[9fans] Gecko based web browser

[Stephen Harris]

Someone was asking about Gecko, which is the layout/rendering engine
used by Mozilla.

There is a small, working web browser thinly built around Gecko alone,
without the Mozilla baggage. It's called Galeon and is starting to 
become popular.  It's at http://galeon.sourceforge.net

Supposedly supports all the latest web standards.

It's about 250k for the compressed source.  Don't know about the libraries
it requires.

-- Steve Harris
   
      Everything you do from now on will be more fun - Windows 95 installation

Re: [9fans] Gecko based web browser

[Andrey Mirtchovski]

Stephen Harris wrote:

> There is a small, working web browser thinly built around Gecko alone,
> without the Mozilla baggage. It's called Galeon and is starting to
> become popular.  It's at http://galeon.sourceforge.net

Oh yeah, it made it to slashdot even...

AFAIK it is tightly coupled with GNOME (they advertise it as a gnome web browser)
which means it exploits the gtk+ libraries. A freebsd port is in the works (if
not completed already) but a plan9 one would require gtk to be ported... And then
we may just as well start porting the entire gnome bloatware... :P

andrey

Re: [9fans] Gecko based web browser

[Randolph Fritz]

On Tue, Jul 18, 2000 at 01:17:34PM -0600, Andrey Mirtchovski wrote:
> Stephen Harris wrote:
> 
> > There is a small, working web browser thinly built around Gecko alone,
> > without the Mozilla baggage. It's called Galeon and is starting to
> > become popular.  It's at http://galeon.sourceforge.net
> 
> Oh yeah, it made it to slashdot even...
> 
> AFAIK it is tightly coupled with GNOME (they advertise it as a gnome web browser)
> which means it exploits the gtk+ libraries. A freebsd port is in the works (if
> not completed already) but a plan9 one would require gtk to be ported... And then
> we may just as well start porting the entire gnome bloatware... :P
> 

But Mozilla itself is not gtk based, so galeon might be a useful
model for a more 9ish version.  To be continued...

-- 
Randolph Fritz
Eugene, Oregon, USA

Re: [9fans] Gecko based web browser

[Randolph Fritz]

On Tue, Jul 18, 2000 at 04:48:55PM -0700, Randolph Fritz wrote:
> 
> But Mozilla itself is not gtk based, so galeon might be a useful
> model for a more 9ish version.  To be continued...
> 

I've downloaded it & had a look.  Basically, Galeon is a thin shell
around ngLayout (*).  Probably ngLayout could be adapted, but I'm not
sure how much of Mozilla would have to come along.

-- 
Randolph Fritz
Eugene, Oregon, USA


* ngLayout is not a trademark of Netscape...but Gecko is.

Re: [9fans] Gecko based web browser

[Michael Dingler]

> > There is a small, working web browser thinly built around Gecko alone,
> > without the Mozilla baggage. It's called Galeon and is starting to
> > become popular.  It's at http://galeon.sourceforge.net
> 
> Oh yeah, it made it to slashdot even...
> 
> AFAIK it is tightly coupled with GNOME (they advertise it as a gnome web browser)
> which means it exploits the gtk+ libraries. A freebsd port is in the works (if
> not completed already) but a plan9 one would require gtk to be ported... And then
> we may just as well start porting the entire gnome bloatware... :P

Erm, I don't think that that anything of GNOME/gtk is
neccesary for the HTML display, parsing etc.
It's just wedged in your typical WIMPy framework due
to those libraries.

Porting Gecko shouldn't require anything from gtk, or
else the Win/Mac/Yadda people would have some serious
problems.

On the other hand, would that be a satisfying solution
at all to have one of the current-generation browsers?
IMHO that's like porting Motif to Plan9. HTML display,
ok, but not the current abomination. Although you'd need 
half an expert system to demoronise existing pages.

...Michael...

Re: [9fans] Gecko based web browser

[Douglas A. Gwyn]

Andrey Mirtchovski wrote:
> AFAIK it is tightly coupled with GNOME (they advertise it as a gnome web browser)
> which means it exploits the gtk+ libraries. A freebsd port is in the works (if
> not completed already) but a plan9 one would require gtk to be ported... And then
> we may just as well start porting the entire gnome bloatware... :P

GTK+/GLIB would be useful on Plan 9 as part of a porting environment,
e.g. in APE.  GTK+ can certainly be implemented without GNOME.

For Chrissakes, if you insist on rolling all your own software you'll
never catch up.  Wouldn't it be better to have a functional Web
browser on your preferred development platform than to have to keep
switching platforms every time you need to access the Web?

Re: [9fans] Gecko based web browser

[Andrey Mirtchovski]

"Douglas A. Gwyn" wrote:

> For Chrissakes, if you insist on rolling all your own software you'll
> never catch up.  Wouldn't it be better to have a functional Web
> browser on your preferred development platform than to have to keep
> switching platforms every time you need to access the Web?

It was a joke.. :)

Anyway, I am morally oposed to Gnome for I love simple things and detest eye candy
(unless it's a game or a screeensaver, which are *supposed* to be pretty :)

yes, you are right, there is simply no way all the software for plan9 could be written
from scratch, but on the other hand if the most importand and frequently used pieces
of software are imported from other OSs, we would hardly be able to stick with the
plan9 look and feel... (I like vi, I use vi, I am productive with vi, I wouldn't want
to see vi ported to plan9, simply because it doesn't fit too well with the system...)

Ah, but what I say does not matter much, since I am a newcomer :) Let me learn more
about P9 before making more statements like the above...

regards: andrey

Re: [9fans] Gecko based web browser

[Randolph Fritz]

On Wed, Jul 19, 2000 at 10:28:45AM -0600, Andrey Mirtchovski wrote:
> 
> Anyway, I am morally oposed to Gnome for I love simple things and
> detest eye candy (unless it's a game or a screeensaver, which are
> *supposed* to be pretty :)
> 

"Less is more."--Mies van der Rohe, 1930?
"Less is a bore."--Robert Venturi, 1970?
-- 
Randolph Fritz
Eugene, Oregon, USA

Re: [9fans] Gecko based web browser

[sah]

...

of course, if we never rewrite anything from scratch...how will we ever
find out what we did wrong, the first time?

Rewriting apps isn't simply an exercise in futility.  It provides the
opportunity to incorporate new concepts, sans hacking old code.


On Wed, 19 Jul 2000, Andrey Mirtchovski wrote:

> "Douglas A. Gwyn" wrote:
> 
> > For Chrissakes, if you insist on rolling all your own software you'll
> > never catch up.  Wouldn't it be better to have a functional Web
> > browser on your preferred development platform than to have to keep
> > switching platforms every time you need to access the Web?
> 
> It was a joke.. :)
> 
> Anyway, I am morally oposed to Gnome for I love simple things and detest eye candy
> (unless it's a game or a screeensaver, which are *supposed* to be pretty :)
> 
> yes, you are right, there is simply no way all the software for plan9 could be written
> from scratch, but on the other hand if the most importand and frequently used pieces
> of software are imported from other OSs, we would hardly be able to stick with the
> plan9 look and feel... (I like vi, I use vi, I am productive with vi, I wouldn't want
> to see vi ported to plan9, simply because it doesn't fit too well with the system...)
> 
> Ah, but what I say does not matter much, since I am a newcomer :) Let me learn more
> about P9 before making more statements like the above...
> 
> regards: andrey
> 

Re: [9fans] Gecko based web browser

[James A. Robinson]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="x-unknown", Size: 2261 bytes --]

And who wants to 'catch up' anyway? =) I liked Linux back in 1992, when
I could actually understand the various components and how they worked
together. Now I look at the mess they've made of configuring xdm and I
get very frustrated.

I think the idea of authoring an n-part web browser would be fun,
and it would let people explore interesting concepts along the way.
Earlier someone said the usefulness of an fs-type web retrievel engine
was limited. I can appreciate the problems that might occur when dealing
with unusual status codes or SSL or HTTP Auth.  But the idea of building
an engine that could automatically give you a proxy system or could
easily be hooked into different browsers is still interesting to me.

I do agree that the hard part is parsing/displaying the html, but it would
still be useful to have a retrieval mechanism that I could use from the
command line.  In their latest book, K&P wrote about a stock-ticker they
grabbed off of Yahoo. They wrote a csv parser library to handle decoding
and displaying the html they grabbed off the url. I think it would be
cool to be able to just do something like

	#!/bin/rc
	echo 'http://finance.yahoo.com/q?s=lu&d=v1' > /mnt/web/new/get
	cat /mnt/web/new/data | awk '{...}'

and run it to get

	LU, 64½, +2.28%, 11,183,600

or whatever.  It's a little more direct than a multi-stage approach of
running wget, putting the results in a temp file, parsing, and cleaning
up.  You don't worry about the retrieval part, it just works. I just
happen to think that might be leveraged by other tools as well.


> of course, if we never rewrite anything from scratch...how will we ever
> find out what we did wrong, the first time?
> 
> Rewriting apps isn't simply an exercise in futility.  It provides the
> opportunity to incorporate new concepts, sans hacking old code.
> 
> 
> On Wed, 19 Jul 2000, Andrey Mirtchovski wrote:
> 
> > "Douglas A. Gwyn" wrote:
> > 
> > > For Chrissakes, if you insist on rolling all your own software you'll
> > > never catch up.  Wouldn't it be better to have a functional Web
> > > browser on your preferred development platform than to have to keep
> > > switching platforms every time you need to access the Web?

Re: [9fans] Gecko based web browser

[Boyd Roberts]

sah@borf.com wrote:

> ....
> 
> of course, if we never rewrite anything from scratch...how will we ever
> find out what we did wrong, the first time?
> 
``plan to throw one away, you will anyway''.

how do you think 8 1/2 got its name?

--
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] Gecko based web browser

[Ralph Corderoy]

Hi,

> For Chrissakes, if you insist on rolling all your own software you'll
> never catch up.  Wouldn't it be better to have a functional Web
> browser on your preferred development platform than to have to keep
> switching platforms every time you need to access the Web?

Are there two separate issues here?  One, new and innovative ways of
representing HTML-based information available via HTTP.  Two, wanting
exact Netscape or Internet Explorer functionality *today* so you can
access those PITA sites that don't function without JavaScript du jour,
etc.

For the second Douglas has a point, we'll never catch up with NS and IE
since they're playing catch up with W3C who are in turn trying to catch
up with NS and IE's latest `extensions' :-)

What about considering a means of running NS or IE on a separate
`server' box and pulling or pushing that across to Plan 9?  Initially,
something like VNC (Virtual Network Computer) might suffice.  More
complex would be allowing a single NS to be the `render server' for
multiple users.  Icky perhaps, but it would free Plan 9 users from the
hungry hoards that want IE and allow them to research new, different,
models.


Ralph.

Re: [9fans] Gecko based web browser

[Christopher Browne]

Centuries ago, Nostradamus foresaw a time when Stephen Harris would say:
>Someone was asking about Gecko, which is the layout/rendering engine
>used by Mozilla.
>
>There is a small, working web browser thinly built around Gecko alone,
>without the Mozilla baggage. It's called Galeon and is starting to 
>become popular.  It's at http://galeon.sourceforge.net
>
>Supposedly supports all the latest web standards.
>
>It's about 250k for the compressed source.  Don't know about the
>libraries it requires.

It may be 250k of compressed source for Galeon, but note that:
   "It requires Gnome and MOZILLA M16."

Those two "code bases" represent a _mite_ more than 250k of code, and
I suspect that the Plan 9 port would be, um, challenging...
-- 
cbbrowne@ntlug.org - <http://www.ntlug.org/~cbbrowne/>
It's hard to tell if someone is inconspicuous. 

Re: [9fans] Gecko based web browser

[Andy Newman]

Christopher Browne wrote:
>Those two "code bases" represent a _mite_ more than 250k of code, and
>I suspect that the Plan 9 port would be, um, challenging...

(Some sanity at last!)

I've been "inside" Mozilla quite a deal and I can guarantee,
1000%, that any port is a decidely non-trivial undertaking.
We're talking about millions of lines of code here guys (my build
of it on FreeBSD takes up 1.5GB of disk and I leave out half of
the bloody thing). And there's pretty much zero documentation on
its internals. Most of the comments from people here seem to indicate
a very casual acquaintance with Mozilla, either that or a naive belief
in the project hype. So here's some tips on a Plan 9 Mozilla port from
some one who's been in the guts of the program in question...

First thing you need to do is write (or port :) a half decent C++
compiler.  Thankfully Mozilla doesn't ask a lot of the library, it
has its own (which needs porting).  But there's no cheating and
going inventing some Plan 9 C++. It has to compile Mozilla which
uses mosts of the bits and pieces C++ has to offer. So when you've
written or ported your C++ compiler you can think about just getting
the build system functional This may need Perl and bash ports and it
may be better and easier rewriting the whole thing rather than mash it
(high brucee) into Plan 9.  The next week can be spent getting the code
compiled without errors.  There's a few thousand souce files and associated
headers, oh, and the IDL compiler will need to be made to work before
compiling anything, I guess I just saw that as part of the build system.
Linking anything correctly is a bonus at this stage. The lack of shared
objects and ld.so may present some issues with the component system
and needs a good looking at. But just getting XPCON going will take
some doing and there's a little assembler in there which will depend
on the compiler's implementation of virtual functions. Needs a good
testing session.  The remaining platform specific stuff might be quite
easy compared to the previous load of work.  An implementation of a
graphics backend, the portable widgets replace the need for any Plan
9 GUI toolkit to be invented, some sort of embedding shell needs to
be implemented (a la the gtk_moz_embed the 250K program uses - the
Mozilla shared libs will add many MBs to the real code and its
run-time memory footprint measures in the tens to hundreds of MB
depending on page complexity). I've left out loads of things that
need porting considerations - JavaScript, the thread library, various
codecs etc...

So get going people, bit of work to do.

Re: [9fans] Gecko based web browser

[miller]

> Supposedly supports all the latest web standards.
                              --------------------

Whose?

Re: [9fans] Gecko based web browser

[Randolph Fritz]

On Tue, Jul 18, 2000 at 09:23:43PM +0100, miller@hamnavoe.demon.co.uk wrote:
> > Supposedly supports all the latest web standards.

W3's.  Really.  :)

-- 
Randolph Fritz
Eugene, Oregon, USA

Re: [9fans] Gecko based web browser

[rob pike]

> W3's.  Really.  :)
I know I can look this up myself, but... does W3 propose a
Javascript standard?

-rob

Re: [9fans] Gecko based web browser

[Howard Trickey]

> I know I can look this up myself, but... does W3 propose a
> Javascript standard?

It's a ECMA standard ("ECMAscript").  Of course, Sun and
Microsoft went their own ways a bit on it, but the language itself
is reasonably well defined and the implementations of it don't
differ all too much; it's the document object model that is the
horror when it comes to different implementations.  W3C has
a standard for it, but IE and Netscape differ widely here
(even different versions of each).

Howard Trickey

Re: [9fans] Gecko based web browser

[Alt]

rob pike wrote:

> > W3's.  Really.  :)
> I know I can look this up myself, but... does W3 propose a
> Javascript standard?
>

Sorry for my 2 cents, again.
but I think that:

Javascript isn't a solution of the problem, of "dynamizing" of the
web-content.
It is partial solution, which a source of incompatibilities.

If you would like to hear my mind....
the WWW is an obsolete thing too.
first the web is not enough interactive,
with it web have a lot of ambiguous standards and semi-standards.


>
> -rob

Re: [9fans] Gecko based web browser

[Douglas A. Gwyn]

Alt wrote:
> the WWW is an obsolete thing too.
> first the web is not enough interactive,
> with it web have a lot of ambiguous standards and semi-standards.

The same could be said for automobiles,
but somehow they're more important than ever in real life.

Re: [9fans] Gecko based web browser

[forsyth]

are the real-audio and flash web formats documented somewhere?

Re: [9fans] Gecko based web browser

[Frank Gleason]

The real-audio format is documented on www.realnetworks.com/devzone.
Somewhere on the site is the source to a referance RTSP player. I
have the link if you need it.

Frank Gleason
RealNetworks

On Wed, 19 Jul 2000 forsyth@caldo.demon.co.uk wrote:

> are the real-audio and flash web formats documented somewhere?
> 

Re: [9fans] Gecko based web browser

[Randolph Fritz]

On Tue, Jul 18, 2000 at 03:30:13PM -0700, Frank Gleason wrote:
> 
> The real-audio format is documented on www.realnetworks.com/devzone.
> Somewhere on the site is the source to a referance RTSP player. I
> have the link if you need it.
> 

I was under the impression that the format is proprietary.  Was I wrong?

-- 
Randolph Fritz
Eugene, Oregon, USA

Re: [9fans] Gecko based web browser

[Frank Gleason]

On Tue, 18 Jul 2000, Randolph Fritz wrote:

> On Tue, Jul 18, 2000 at 03:30:13PM -0700, Frank Gleason wrote:
> > 
> > The real-audio format is documented on www.realnetworks.com/devzone.
> > Somewhere on the site is the source to a referance RTSP player. I
> > have the link if you need it.
> > 
> 
> I was under the impression that the format is proprietary.  Was I wrong?
> 

RealAudio is streamed in RTSP, an open streaming protocal. The proprietary
part is the codec. I don't know that the referance player (and server if
I remember correctly) implement for the codec, but I am sure that if
it is a Real codec it's not going to be very current. I'll have a 
look at the readme and see what the story is.

Frank



> -- 
> Randolph Fritz
> Eugene, Oregon, USA
> 

Re: [9fans] Gecko based web browser

[Skip Tavakkolian]

Internals of the RA/RV are proprietary and their formats are not publicly
available. RealMedia is the container type which encapsulates RA/RV
tracks, etc. RM type is described in the RealSystem SDK (formerly RMASDK).
You can get the SDK from
http://www.realnetworks.com/devzone/downlds/index.html

The streaming control protocol is RTSP, which is well documented (IETF).
Different implementations are interoperable. The stream payload format
is RTP with some additional headers.

I have some thoughts on how one could support Real types under Inferno
(for Windows) using the RMASDK, if you are interested.

At 12:02 AM 7/19/00, forsyth@caldo.demon.co.uk wrote:
>are the real-audio and flash web formats documented somewhere?
>
>

Re: [9fans] Gecko based web browser

[Theo Honohan]

forsyth@caldo.demon.co.uk wrote:
>are the real-audio and flash web formats documented somewhere?
>

See http://www.openswf.org for links to most of the available Flash info.

Re: [9fans] Gecko based web browser

[forsyth]

>>are the real-audio and flash web formats documented somewhere?

>Internals of the RA/RV are proprietary and their formats are not publicly
>available. RealMedia is the container type which encapsulates RA/RV

much more as i expected (which is why i asked).
i knew about the stream format (more or less) because that's publicly documented.
some web content that end users want to have is not.
it's only available via binary plug-ins, and some -- perhaps many -- of those
only work under windows (and sometimes only within
a browser, though that might not be true of realaudio).
by `format' i meant the whole thing.
it seems a bit pointless to implement the transport without being
able to replay the sounds it contains.

Re: [9fans] Gecko based web browser

[Lucio De Re]

On Wed, Jul 19, 2000 at 08:18:36AM +0000, forsyth@caldo.demon.co.uk wrote:
> it seems a bit pointless to implement the transport without being
> able to replay the sounds it contains.

Not altogether, one may want to record it, or perhaps we can figure a
way to pipe to a win box, if there's no other option.  Consider that
squid is not entirely superfluous :-)

I think we should look at a browser that has the facilities for
plug-ins, make the latter as simple as possible and let history takes
its course.

I think it was Diamond that eventually regretted their decision not to
disclose to the XFree86 boffs how their VGA adapters operated.

And, I hasten to add, if we have the infrastructure in place, we can
easily ride the wave of supply meeting demand (consider CSS as a case
in point) currently being driven by the Linux community.  But we do
need to build the foundations for it (and a little more, when it comes
to web browsers and, I'd like to repeat, graphic rendering engines).

++L

PS: I think this forum has been wonderful in one particular respect,
namely in discouraging kitchen-sinkenitis, with sensible reasoning.
I'd like to see more ideas being proposed here, and the same careful
consideration given to them.  There are many neophytes that, not
unlike me, still do not altogether grasp the philosophy behind Plan 9
and I believe it does not hurt to emphasise it by example on a regular
basis.  There are also many capable developers that only need some
encouragement to take Plan 9 further.

Re: [9fans] Gecko based web browser

[Randolph Fritz]

On Wed, Jul 19, 2000 at 08:18:36AM +0000, forsyth@caldo.demon.co.uk wrote:
> 
> much more as i expected (which is why i asked).  i knew about the
> stream format (more or less) because that's publicly documented.
> some web content that end users want to have is not.  it's only
> available via binary plug-ins, and some -- perhaps many -- of those
> only work under windows (and sometimes only within a browser, though
> that might not be true of realaudio).  by `format' i meant the whole
> thing.  it seems a bit pointless to implement the transport without
> being able to replay the sounds it contains.
> 

On the other hand, Ogg Vorbis *is* an open audio compression format.
I don't know much about it, but more can be found at
<http://www.xiph.org/ogg/vorbis/index.html>.

-- 
Randolph Fritz
Eugene, Oregon, USA

Re: [9fans] Gecko based web browser

[Jonathan Sergent]

On Wed, 19 Jul 2000 07:54:18 GMT,
forsyth@caldo.demon.co.uk <forsyth@caldo.demon.co.uk> wrote:
>it's only available via binary plug-ins, and some -- perhaps many -- of those
>only work under windows (and sometimes only within
>a browser, though that might not be true of realaudio).
>by `format' i meant the whole thing.
>it seems a bit pointless to implement the transport without being
>able to replay the sounds it contains.

There are RTP (RFC 1889) payload types for several compression algorithms
which are free, and that could be implemented without too much trouble.

I'm not sure how hard it is to get Real's server to stream most of them,
but Apple's QuickTime streaming stuff (also controlled by RTSP, RFC 2326)
supports several standard codecs and standard RTP payload types for audio
and video.  (They have their proprietary formats as well, but it's not
hard to produce content in the free codecs; they just aren't typically
as well suited for low bitrate streaming or aren't as high quality).

It's not hard to throw together a simple RTSP and RTP client.  For some
of the easy audio codecs (i.e. uLaw) it should be fairly simple to throw
together something to do playback for Plan 9.  I think the JPEG stuff
should probably be easy with reuse of the existing JPEG display code once
you depacketize the stuff.  The RTSP part could probably be done in rc.

You usually don't have to do much of a browser plugin for these things.
There's nothing wrong with showing it in another window.  The page
does often use an EMBED tag but you could send those to the plumber
and have it know to pop up the RTSP client for it.

Getting a server for this stuff on Plan 9 is probably a bit more
challenging...


--jss.

Re: [9fans] Gecko based web browser

[rob pike]

I have a summer student, Jeff Brown, working with me to try
some of these ideas out.  There are already indications that
some of the parts will work out well, and also that we have
seriously underestimated what's involved in others.  I hope
to have something trivial but functional before long.  Once
I am comfortable with the overall architecture, I'll lob the
code over the wall and see if we can get some critical mass
on the project.

Web access is very important.  Web browsers are very useful.
But if you stop there, you're missing a lot of opportunity.

-rob

Re: [9fans] Gecko based web browser

[George Coulouris]

<vaguely_related_tangent>

I remember a http: device back on my Amiga that would make the network look
like a file, and allow any old program access to http. So, in the same way
you would view a local file, e.g.

multiview dh0:docs/foo.txt,

you could do

multiview http:foo.bar.com/foo.txt

URL formatting aside, this was a neat trick. Particularly with
datatype-aware programs like multiview, which effectively had plugins to
deal with html, gif, jpg and so forth.

</vaguely_related_tangent>

-- 
George Coulouris - http://www.tc.cornell.edu/~glc5/

Re: [9fans] Gecko based web browser

[James A. Robinson]

Someone just pointed out 'hget ...|awk ...' would do what I was talking
about. Yes, I did know about it, but perhaps I should explain some of
the advantages I could see coming out of a web retrieval engine.

I realize a lot of this could be built into a stand alone binary, I
just don't see the point of doing that instead of an easier to navigate
fs-style server.  In any case, after this I won't harp on the subject
any more.

cache   A cache is a wonderful thing. This is from my point of view
        as one of the poor schmos who gets paged when Science Magazine
        has an article or three that a million people want *right now.*
        A few weeks ago they published a breaking article about water
        on Mars, an article about some new AIDS research, and an article
        about dinosaurs who had feathers.  This brought the merry hordes
        breaking down our door, and we were seeing 30 hits per second
        sustained for 48 hours.

proxy   You start up webfs on your firewall machine, and export the
        service to everyone on the local net.  They bind the firewall's
        /webfs to their own root, and off they go (taking advantage of
        the cache, and not having to futz with http vs https proxys like
        might have to in netscape)

past    Anyone else thing that IE actually has a pretty spiffy history
        of last visted links?  The break down into Yesterday, Last Week,
        2 Weeks Ago, etc., is a lot nicer than NS's default history buffer.
        Imagine what you could do in terms of an fs system:

        diff /webfs/past/20000718/bmj.com/index.dtl /webfs/now/bmj.com/index.dtl

        Of course I don't pretend to know how one can handle the file
        heirarchy stuff.  As I wrote to someone in private e-mail
        awhile ago, I don't think that just because a url has a '/'
        that it should automatically be a candidate for an fs storage
        heirarchy.  But I do agree that a LOT of it CAN be mapped.
        What if you could do searches in the cache of places you've
        visited over the past few weeks? For example, you remember
        seeing a real nice algorithm, but you now you've forgotten some
        important detail. You can visit Google and comb the web again,
        but if you know it's somewhere in that cache on local fs...

anon    I can't remember if it was Bell Labs or AT&T Labs, but someone at
        one of those places wrote about a neat proxy server which helped
        protect your identity.  You browsed via the proxy, and it
        would subsitute codes like '\@u' which you POST to forms with
        an expanded username like 'anon10007' or what-not.  It could
        generate a unique e-mail address for each '\@e' sent domains so
        that you could tell which corperation sold your e-mail address.

junk    Anyone else use the junkbuster? It strips out banner ads and other
        ad junk, replacing graphics with a transparent gif (and since
        it is transparent it can expand to the size of the gif it's
        replacing without looking weird). So sites look normal, but you
        don't have to view the ads.  It also ignores HREF to places
        like doubleclick.  Wouldn't it be nice to be able to write a
        set of common rules to control such features, and allow users
        to bind their own /webfs/junkbuster/rules into place?

secure  Strip out postscript or junk javascript according to default or
        user rules.

I guess all these are variations on a theme. Like I said, I understand
you can do all this in a stand alone binary. But for me it just seems to
call out for a fs style approach -- I'm under the impression that it would
be easier to manage than a bazillion command line options like wget has:

        ; wget --help
        GNU Wget 1.5.3, a non-interactive network retriever.
        Usage: wget [OPTION]... [URL]...
        
        Mandatory arguments to long options are mandatory for short options too.
        
        Startup:
          -V,  --version           display the version of Wget and exit.
          -h,  --help              print this help.
          -b,  --background        go to background after startup.
          -e,  --execute=COMMAND   execute a `.wgetrc' command.
        
        Logging and input file:
          -o,  --output-file=FILE     log messages to FILE.
          -a,  --append-output=FILE   append messages to FILE.
          -d,  --debug                print debug output.
          -q,  --quiet                quiet (no output).
          -v,  --verbose              be verbose (this is the default).
          -nv, --non-verbose          turn off verboseness, without being quiet.
          -i,  --input-file=FILE      read URL-s from file.
          -F,  --force-html           treat input file as HTML.
        
        Download:
          -t,  --tries=NUMBER           set number of retries to NUMBER (0 unlimits).
          -O   --output-document=FILE   write documents to FILE.
          -nc, --no-clobber             don't clobber existing files.
          -c,  --continue               restart getting an existing file.
               --dot-style=STYLE        set retrieval display style.
          -N,  --timestamping           don't retrieve files if older than local.
          -S,  --server-response        print server response.
               --spider                 don't download anything.
          -T,  --timeout=SECONDS        set the read timeout to SECONDS.
          -w,  --wait=SECONDS           wait SECONDS between retrievals.
          -Y,  --proxy=on/off           turn proxy on or off.
          -Q,  --quota=NUMBER           set retrieval quota to NUMBER.
        
        Directories:
          -nd  --no-directories            don't create directories.
          -x,  --force-directories         force creation of directories.
          -nH, --no-host-directories       don't create host directories.
          -P,  --directory-prefix=PREFIX   save files to PREFIX/...
               --cut-dirs=NUMBER           ignore NUMBER remote directory components.
        
        HTTP options:
               --http-user=USER      set http user to USER.
               --http-passwd=PASS    set http password to PASS.
          -C,  --cache=on/off        (dis)allow server-cached data (normally allowed).
               --ignore-length       ignore `Content-Length' header field.
               --header=STRING       insert STRING among the headers.
               --proxy-user=USER     set USER as proxy username.
               --proxy-passwd=PASS   set PASS as proxy password.
          -s,  --save-headers        save the HTTP headers to file.
          -U,  --user-agent=AGENT    identify as AGENT instead of Wget/VERSION.
        
        FTP options:
               --retr-symlinks   retrieve FTP symbolic links.
          -g,  --glob=on/off     turn file name globbing on or off.
               --passive-ftp     use the "passive" transfer mode.
        
        Recursive retrieval:
          -r,  --recursive             recursive web-suck -- use with care!.
          -l,  --level=NUMBER          maximum recursion depth (0 to unlimit).
               --delete-after          delete downloaded files.
          -k,  --convert-links         convert non-relative links to relative.
          -m,  --mirror                turn on options suitable for mirroring.
          -nr, --dont-remove-listing   don't remove `.listing' files.
        
        Recursive accept/reject:
          -A,  --accept=LIST                list of accepted extensions.
          -R,  --reject=LIST                list of rejected extensions.
          -D,  --domains=LIST               list of accepted domains.
               --exclude-domains=LIST       comma-separated list of rejected domains.
          -L,  --relative                   follow relative links only.
               --follow-ftp                 follow FTP links from HTML documents.
          -H,  --span-hosts                 go to foreign hosts when recursive.
          -I,  --include-directories=LIST   list of allowed directories.
          -X,  --exclude-directories=LIST   list of excluded directories.
          -nh, --no-host-lookup             don't DNS-lookup hosts.
          -np, --no-parent                  don't ascend to the parent directory.
        
        Mail bug reports and suggestions to <bug-wget@gnu.org>.

Re: [9fans] Gecko based web browser

[miller]

> What about considering a means of running NS or IE on a separate
> `server' box and pulling or pushing that across to Plan 9?  Initially,
> something like VNC (Virtual Network Computer) might suffice.

I think a few of us are already doing exactly that ...

Re: [9fans] Gecko based web browser

[James G. Stallings II]

'scuse me for butting in on a tired thread, but has anyone considered a
divorce from contemporary browser technology?

Something, perhaps, that retrieved the content via the http protocol and
left the display and formatting to the user's disretion? with/without
pictures, with/without frames, with/without text formatting, etc? perhaps
some sort of pluging registry similar to that of the open-source image
processing tool "The GIMP"?

Personally, I think we need to "get out of the box" when thinking about the
web and browsers, and let's face it - a new operating system that either
completely lacks or is dependent on another O/S for utilising the web is a
dead end in todays environment....

Open to comments, suggestions, flames, etc

Cheers,
-James

miller@hamnavoe.demon.co.uk wrote:

> > What about considering a means of running NS or IE on a separate
> > `server' box and pulling or pushing that across to Plan 9?  Initially,
> > something like VNC (Virtual Network Computer) might suffice.
>
> I think a few of us are already doing exactly that ...


__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com

Re: [9fans] Gecko based web browser

[Matt]

----- Original Message -----
From: "James G. Stallings II" <alteridentity@yahoo.com>
To: <9fans@cse.psu.edu>
Sent: 26 July 2000 18:50
Subject: Re: [9fans] Gecko based web browser


> 'scuse me for butting in on a tired thread, but has anyone considered a
> divorce from contemporary browser technology?
>
> Something, perhaps, that retrieved the content via the http protocol and
> left the display and formatting to the user's disretion?
well if you've read my comments on the subjkect you'll know I agree with you
there

the document should be retrieved and mounted and then the rendering engine
attached

content creation tools such as Dreamweaver are increasingly using Javascript
to control pages.

Designers, esp. the newer ones, are quite happy to use script all over the
place and I think that the web will become increasingly unusable to
non-script enabled browsers. I've just started at a new web design shop and
many of the designers there don't even know about text only browsers and as
such don't always design their sites to degrade gracefully. I hope to
educate my new co-workers.

Anyway my point is that version 4 browsers are beyond simple html display
any any development of a browser had better take CSS-p and css-2 into
account if it's from scratch.

As i mentioned mounting the document and having the DOM exposed as a FS
would be good and any links could be followed and added to the FS



see http://www.w3.org/DOM/ if you want to see the spec but a snippet :

1.1.1. The DOM Structure Model
The DOM presents documents as a hierarchy of Node objects that also
implement other, more specialized interfaces. Some types of nodes may have
child nodes of various types, and others are leaf nodes that cannot have
anything below them in the document structure. The node types, and which
node types they may have as children, are as follows:

Document -- Element (maximum of one), ProcessingInstruction, Comment,
DocumentType
DocumentFragment -- Element, ProcessingInstruction, Comment, Text,
CDATASection, EntityReference
DocumentType -- no children
EntityReference -- Element, ProcessingInstruction, Comment, Text,
CDATASection, EntityReference
Element -- Element, Text, Comment, ProcessingInstruction, CDATASection,
EntityReference
Attr -- Text, EntityReference
ProcessingInstruction -- no children
Comment -- no children
Text -- no children
CDATASection -- no children
Entity -- Element, ProcessingInstruction, Comment, Text, CDATASection,
EntityReference
Notation -- no children
The DOM also specifies a NodeList interface to handle ordered lists of
Nodes, such as the children of a Node, or the elements returned by the
Element.getElementsByTagName method, and also a NamedNodeMap interface to
handle unordered sets of nodes referenced by their name attribute, such as
the attributes of an Element. NodeLists and NamedNodeMaps in the DOM are
"live", that is, changes to the underlying document structure are reflected
in all relevant NodeLists and NamedNodeMaps. For example, if a DOM user gets
a NodeList object containing the children of an Element, then subsequently
adds more children to that element (or removes children, or modifies them),
those changes are automatically reflected in the NodeList without further
action on the user's part. Likewise changes to a Node in the tree are
reflected in all references to that Node in NodeLists and NamedNodeMaps.

Re: [9fans] Gecko based web browser

[Lucio De Re]

On Thu, Jul 27, 2000 at 08:43:23AM +0100, Matt wrote:
> 
> Designers, esp. the newer ones, are quite happy to use script all over the
> place and I think that the web will become increasingly unusable to
> non-script enabled browsers. I've just started at a new web design shop and
> many of the designers there don't even know about text only browsers and as
> such don't always design their sites to degrade gracefully. I hope to
> educate my new co-workers.
> 
Why not just encourage them, to the point where more computing power
than would put man on the moon many times over is minimally essential
to read a web page?

Surely, there must be some way to exploit this insanity?  Or is it
just part of the growing technological gap?

++L

Re: [9fans] Gecko based web browser

[Matt]

> > Designers, esp. the newer ones, are quite happy to use script all over
the
> > place and I think that the web will become increasingly unusable to
> > non-script enabled browsers. I've just started at a new web design shop
and
> > many of the designers there don't even know about text only browsers and
as
> > such don't always design their sites to degrade gracefully. I hope to
> > educate my new co-workers.
> >
> Why not just encourage them, to the point where more computing power
> than would put man on the moon many times over is minimally essential
> to read a web page?
>
> Surely, there must be some way to exploit this insanity?  Or is it
> just part of the growing technological gap?

Actually I find client side scripting very useful.

It prevents round trips to the web server and utilises clock cycles
otherwise wasted on the client side.

On one project I use XML to store the details of the stories available and
display hidden DIV's containing the headlines when the section headers are
mouseovered (a new word :-?).
I only have to load the headlines into the browser once when the first page
is loaded and I cn re-arrange the order of the stories as necessary (by
date, author, category etc.) without any http requests.

Clients being able to manipulate a dataset and return the results to the
server is also useful
(or it will be as soon as I can find a use for it :)

I do recognise the technology gap but the desire to execute code on the
client is a strong one and as more people utilise it beyond simple
mouseovers it will become an enriching experience.

You can develop quite sophistcated applications with the DOM and a scripting
language it's just that people have shied away from it as yet in the
internet world and kept it in the the world of the intranet where the
browser platform can be specified. Sadly there are plenty of differences
between IE, Netscape and the upcoming Mozilla that make cross browser
implementations quite hairy (and I've been tackling then all day today -
things position differently in each browser even when specified by the
pixel!).

The days of chucking static html to the browser are leaving us and saying
"but all I want to do is display HTML so sod it" may well be valid for your
own site but increasingly you will be locked out of some of major web sites
and plenty of the minor ones coded by people who only test on IE.

Matt