[snipped]

People-wise, I think we have:
Me: Coding
MarcoF: Testing
Monkeyson: Coding
Andrew Poole: GUI Templates
Moss: Testing, Docs

So, to conclude, yes, I am serious, but think we ought to concentrate one thing at a time - a web browser is a big project.<br><br>[Edited by Hertzsprung at 09:20, 19/4/2002]

hmm, if you want perfect HTML rendering. according to the standards out there, I guess a good point to start is to port an open source renderer.. I think w3c has one available (or HAD one?)
but that is then for the standard check, more or less.. not for speed..

i must admit I am quite happy with the way !Oregano handles HTML/CSS, but indeed, there is quite some things left to be desired.

a browser rendered should take into account:
- HTML (4?)
- CSS (2)
- XML (getting more and more popular)
- javascript (version?)

i think those are the 4 fundamentals.. lots of work where XML might be lower priority.
then, you need:
- png, gif, jpg, csv (?) renderers
- possibility of plugins
- http, ftp, gopher protocol
- https

whoa.. even *more* work

well, I'm in

Correct me if I'm wrong...

w3c do have a browser - I have checked it out - it looked a bit crap to be honest .

HTML 4 is definately a good starting point I think. CSS also needed. XML and JavaScript should be lower priority, I think. Could we pinch PNG/GIF/JPG renderers from another program. There must be some modules we could use to do that bit for us.

I think http would be a good starting point There must be some modules on RISC OS to handle the protocols you mention? Like I say, I'm not familiar with the networking side of it - I'm not internetted on my lowly A5000

It's no secret that drobe.co.uk was writing a browser ages ago, in fact drobe.co.uk was created as the home page portal for the broswer. In the end, we just stuck to the website

I can't remember how far we got, I remember starting to write a html renderer in assembler. If you need any help BASIC or C wise, I'm happy to lend a hand, if you need it. I reckon you'll need more than 2 coders seeing as you'll have to take care of:

- Sockets, ports, proxies, http fetchers, url launchers, cookie manager etc.
- html p4rsing and rendering, dynamic UI to provide forms and (spit) frames, CSS handling, the code to redraw the webpage will be fun
- memory manager to allocate memory to html viewer and fetchers
- plugin manager to launch separate image converters
- javascript fun
- UI system to provide windows, menus, choices windows, hotlists, histories etc.
- I'm sure there's more I've forgotten, like dealing with non Latin character sets (encoding), printing webpages, searching pages, security features, SSL and so on.

I recommend that your write as much as possible in a higher language such as C and leave BASIC to being the glue for smaller bits. Also, please don't fall into the trap of planning the application for 6 months and not actually doing anything: get designing and coding, you can change stuff as you go along.

I think that's it, now I can shut up and wish you luck

Chris

Any ideas for what windows I will need to make..

browser window
toolbar
choices - what do we want in it
info box
startup banner - leave till last (low priority)
realm auth box
message boxes

anything else?

I reckon that we can get to make the twirly thingie that twirls while pages load and possibly some other images...

I'll post later when I have got something there.

Have we got a name yet? for now I'll put Iconbar Web Browser while we think.

No, I still don't think we have a name.... Cummon people, that's the easy bit!
As soon as we have a name, I'll set up the SForge project

We need to get this list down to something more managable:

- Sockets, ports, proxies, http fetchers, url launchers, cookie manager etc.

How much of this has already been written?

- html p4rsing and rendering, dynamic UI to provide forms and (spit) frames, CSS handling, the code to redraw the webpage will be fun

This is the bit I'd like to concentrate on

- memory manager to allocate memory to html viewer and fetchers

guess there's no avoiding that

- plugin manager to launch separate image converters

that too

- javascript fun

JavaScript is lower priority

- UI system to provide windows, menus, choices windows, hotlists, histories etc.

That's the easy bit

- I'm sure there's more I've forgotten, like dealing with non Latin character sets (encoding), printing webpages, searching pages, security features, SSL and so on.

I think I'll go and have a lie down....

Oregano, Fresco... Bilco?

Phyton, Lynx, PussyCat?

-Faith (as in, have faith, we'll finish it soon - and also a nice sly E.D. ref)

-CROW (cool risc os web) or CROWBAR (cool risc os web browser, ask rich!)

-ARCWB (A Really Cool Web Browswer - hmm, sounds familiar...)

-RWB (RiscOs Web Browser - it could have a Red, White and Blue logo!)

-FishNet (sorry)

-JCB (Javascript Compliant Broswer)

-ROW (RISC OS Web)

-BETHAN (BEtter THAn Netscape)

-!BROWN (Browse RISC OS Web Net)

-ROB (RISC OS Browser)

-!Rib (Riscos Internet Browser)

...more?

You want MORE?!

(and you can then rip off oregano's desert island sunny marketing style thing)

Anyway, I've put the C source of what I wrote up at http://www.strcprstskrzkrk.co.uk/browser.zip if anyone's interested. There's simple CSS parsing and the start of a layout algorithm. I'll contribute programming if you set up a project.

James

I'll have plenty of free time over summer - plenty of time for writing documentation, testing, basically anything that doesn't involve actual programming. (I know rudimentary C, but that's hardly enough for this level of programming. I could probably learn quite a bit off you lot!)

Oh, name change needed because somebody's already nicked surf at sourceforge. Erm. Surfer? NetSurf? Windsurf? I'll have to choose one of those, I think.

http specs: http://www.ietf.org/rfc/rfc2616.txt
ftp specs: http://www.ietf.org/rfc/rfc959.txt
html specs: http://www.w3.org/TR/html4/
xhtml specs: http://www.w3.org/TR/xhtml1/
css specs: http://www.w3.org/TR/REC-CSS1
tcp/ip info: http://www4.ulpgc.es/tutoriales/tcpip/entrada/3376fm.html
socket intro: http://www.iconbar.com/programming/network/
more sockets: http://www.ecst.csuchico.edu/~beej/guide/net/html/
more sockets: http://www.uwo.ca/its/doc/courses/notes/socket/
server/client examples: http://pont.net/socket/
dillo, small browser, something you'd start off aiming for: http://sourceforge.net/projects/dillo/

Ok, that's enough of links I've found in the past to be quite cool. A lot of bed time reading Essentially, the system would be a demand driven system. The browser would own the toolbar and when given a URL to fetch, it would call the fetcher and place it in a queue. The queue is polled until an event occurs, such as the fetcher receiving data. The memory manager allocates chunks of memory to slot the fetched data into. The p4rser is queued so that it translates the html/css/xhtml into a simple binary format for the redraw code to quickly use to reproduce the webpage on the screen. The p4rser also queues up more fetchers to grab images required for the page. The redrawer is also queued to redraw the translated html/css/xhtml as it comes in. When all done, the queue can be used to close the fetcher and inform the memory manager that we're done. When the WIMP tells us to redraw the page, we can use the translated binary to reproduce the webpage.

Also, the fetcher should be configured to work with a cache manager so pages and images are first pulled from disc then from the network. Also, the cache manager is queued to save rendered pages and fetched images to disc. A image manager will be needed to vector jpg/png/gif conversions out to separate applications, these all exist. RISC OS Select includes jpg and png suport as standard. That's just the fetch/render/redraw system. The actual network fetcher and p4rser sub-systems will be mucho complexo than this, although my StatusD software does do a good work of scanning through files, picking out tags and identifying and processing them. That's 2/5ths of the way there.

Then there's the plugin for flash/java/the works system- there's so many protocols to choose from, we don't need to devise our own. The UI is starightforward, the hotlist and history managers will be more interesting. I can see us using linked lists and panes.

Err, that's all I can think of for now. I've got some other work to do. T'will be interesting to see how this pans out.

Chris

I will have some time over summer also. Sure we can't entice you into doing some rudimentary C? I haven't done C in aaaaaages - I've been doing Python (seriously cool language) at work. Looking forward to this.

Oh, name change needed because somebody's already nicked surf at sourceforge. Erm. Surfer? NetSurf? Windsurf? I'll have to choose one of those, I think.

now the name is not very important, but what about BROS? (Browser RISC OS)? (yeah, didn't meet the deadline of 2hrs, I just got back to my RPC)

What do you consider to be the basics? *relatively* easy? I'm not too sure about that

IMO, of course!

Err, that's all I can think of for now. I've got some other work to do. T'will be interesting to see how this pans out.

Chris

Looks good Chris. It will be interesting...

Surely the main work here is to get the basics done. Once they are over, it should be *relatively* easy to add CSS stuff, for instance, shouldn't it?

The basics? You could write a basic broswer that just telnetted to the webserver required on port 80, GET <file> and then displayed the returned page. Very cute.

Of course this application would have to be modular. By the time the UI is finished, the renderer and fetcher sub-systems would still be in a very early stage however as they are improved, the newer sub-systems would be able to be built with the existing completed bits with little fuss. Provided the system as a whole is designed well.

Essentially, you'd need: queue manager, simple fetcher, simple text renderer, UI to provide this. Even this is a couple of weeks work for someone in their spare time but it can be easily expanded upon if you think 'modular'

Chris

*moss is fired up*

Yep... modularity is the key And who knows, I may learn so much from the project that I could properly contribute to the programming later on.

*moss is fired up*

I don't mean to plug but this is true. Even if the browser doesn't take off, there's so muchyou can learn by getting your hands dirty. I've recently been rewriting EasyGCC in C and I've learnt so much from doing this.

Chris

GET /index.php HTTP/1.1\r\nConnection: closed\r\nHost: www.drobe.co.uk\r\n\r\n

Bonus points if you get the raw html redrawn in a window

Chris

I don't mean to plug but this is true. Even if the browser doesn't take off, there's so muchyou can learn by getting your hands dirty. I've recently been rewriting EasyGCC in C and I've learnt so much from doing this.

Chris

*goes off to download EasyGCC*

I have submitted our proposal for NetSurf to SourceForge. Hopefully I will here from them soon. I shall let you know...

Netsurf.. mwa, not bad..

except that it is used *a loT*:
http://www.netsurf.ch/
http://www.netsurf.com
http://www.netsurf.de
http://www.netsurf.net
etc..

[Edited by Hertzsprung at 13:46, 19/4/2002]

etc...
oh, and anyone interested in writing a decent email client with pop3 protocol built-in (I hate the usage of a seperate pop3 handler..)

[Edited by mfrissen at 14:07, 19/4/2002]

just to make sure:
is there consensus on:
- language (my bet: c)?

Sounds good. Encourages logical and structured programming.

- library (is it going to be a port from *nix -- UnixLib needed)

I don't understand what you mean. If you're suggesting that someone ports a web browser from *nix then you need to find out about this little barrier called gtk. All the socket swis/calls are provided by the RISC OS internet stack.

- compiler set (all developers should use the same suite, otherwise you'll get weird side effects and communication issues regarding switches and such)

This is always a problem as some people don't have norcroft and only have GCC -which isn't necessarily bad, you know I'm an advocate for GCC

- CVS (eh, I guess sf arranges that one)

You'll still need the client and be proficient in it. It's essential given the likely number of people contributing.

There's a large number of tools that will be required by people. Things like gerph's !Console for debugging to start off with.

Chris

Keep it open source, obviously. I do think it needs proper promotion to make this worth-while. Still, better create the damn thing before we argue on promotion

just to make sure:
is there consensus on:
- language (my bet: c)?

You could alway borrow bits from Mozilla. I would actually say that web browsers are a prime candidate for C++ rather than C.

- library (is it going to be a port from *nix -- UnixLib needed)

Or netlib. To make life really simple, a port of STLport would help no end. The STL with GCC is not very good to say the least.

- compiler set (all developers should use the same suite, otherwise you'll get weird side effects and communication issues regarding switches and such)

If it's in C++, there is only one compiler up to the job

- CVS (eh, I guess sf arranges that one)

Correct.

etc...
oh, and anyone interested in writing a decent email client with pop3 protocol built-in (I hate the usage of a seperate pop3 handler..)

Why duplicate something that is already out there? I would have it simply that you could call up Pluto, MPro or Marcel from within the application rather than have it's own mail software. Mozilla mail sucks big time.

What I would also suggest is that prior to a single line of code getting written, it is fully mapped out with a step through pathway of the main areas of source. Second to that, follow the same sort of setup as GCC. There it is one person (Nick Burett) with overall control and a pile of contributers. All code has to go through him before it's committed to CVS.

There is, of course, one big problem which none of the RISC OS browsers has *really* managed to work out and that's threading (yes, I know there is a partial port of the mozilla pthread library, but it's rather incomplete and there is also the Simtec threading module, but that has, um, problems). WXL does it by starting background tasks via "helper" apps, Browse decodes and places on the fly and Oregano almost gets it right. Fresco is just crap.

Crack pthreads and crack STLport and you're there - the UI can be done via the toolbox (or better still via Desk).

Sorry if that's a bit of a downer, but it's better to be realistic before setting off than getting 5% through and finding it's a turkey due to the libs not being there or are not up to the job.

[Edited by bluebottle at 21:19, 20/4/2002]