(Lets Make a RISCOS Browser)

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

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?

I've been doing Python (seriously cool language) at work. Looking forward to this.

[ot]How's python doing on ROS, any good? I used to work with it on my *nix, and rather liked it.

now the name is not very important, but what about BROS?

NO!

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

Sounds good.. It may be possble to use some basic or assembler (or both!) to link bits..

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

Ah. I've got Acorn Desktop C version.. 4 I think.. I never did get GCC to work. I've also got EasyC I think lurking somewhere from when I bought the computer...

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

There is a web based CVS on the SF website.

BTW, I've started a simple template set, and I'll have a look into other browsers across the board (windows and linux ones too) to see the general look and feel of a browser. Are we modelling on any particular one?

I need to change machines to do anything else now.. let me power on the RiscPC...

Will we be able to set something more permanent up on the SF website to discuss this or shall I lend you a bit of my F9 space? (I've got plenty of F9 space... and we can't really use the TIB forums for this can we?)<br><br>[Edited by andypoole at 16:21, 19/4/2002]

[Edited by andypoole at 16:22, 19/4/2002]

Netsurf.. mwa, not bad..

except that it is used *a loT*:

Gah! It'll do fine for the sourceforge name - the product doesn't have to be called the same thing. Personally I thought !Link would be kind of cute.

I'd promise to do some coding in my spare time but (a) I don't have a lot of spare time (b) given my track record, it's best not to promise things before they exist and (c) other nasty stuff. It's (c) I'm most concerned about. Shame, as I did my dissertation on HTML parsing. It was pretty evil though, as I didn't really know how to code properly back then.

Even a pars-r that takes valid HTML is a knotty problem. Considering browsers are meant to cope with invalid (elements in the wrong place), badly formed (tags don't match) and just plain broken HTML (mismatched quotes, <> ), writing a decent pars-r is a very interesting problem.

P.S. Don't even try to write one in anything less than C. I wouldn't even like to write one in anything less than C++/Java (half decent OO is ideal for SGML - but Python/Perl OO isn't even half decent). Hell, don't write anything that doesn't output AOF at least.

[Edited by ninj at 19:18, 19/4/2002]

You worry me. A title is a title. It can be changed. You have bigger things to worry about:

http, ftp: Acorn's Browse modules for these are available from http://www.castle.org.uk/oregano/orgsupp.htm#boot
It would be worth using them, at least until you clone better versions.
html, xhtml, css: This is the most difficult part, I'd suggest using Mozilla's renderer, Gecko, writing your own is A LOT of work. If you see what DHTML can do now (Play Asteroids, fake a desktop with draggable windows, scrollbars etc, all in HTML) and compare it to what Fresco/Browse can do, it's a whole new level, and in a year or 5 when you've finished it it'll be out of date again. If you do try to write your own, make sure you have the DOM structure from the start so CSS and JS will work properly.

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.

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.

K-Meleon (A Windows Gecko based browser) and I think recent Mozillas have a nice feature to stop windows opening when you haven't clicked something, which reduces popup ads.

Fresco has some great features: F8 to edit a page via OLE, toolbar buttons to turn on/off JS and Images, menu opens for turning off colours, and frames/tables for testing, the Image menu to save/info/reload an image.

In conclusion, it's possible, it's difficult, it'll take a while. Try to make sure your code is flexible enough to work with future requirements, otherwise your work will be wasted. Copy/steal what's already been done, a good design is the basis of a successful program, everyone has seen programs that tried to extend beyond breaking point.

If you make everything modular and base what you can on existing systems you can use things already written whilst you write the important parts, http/ftp/file/gopher modules, nested wimp, jpeg, toolbox stuff, esp toolaction for forms, webserve, wget/cURL. Apparently WebsterXL can even be used as a plugin which could be useful for testing to start with.

BTW, I've started a simple template set, and I'll have a look into other browsers across the board (windows and linux ones too) to see the general look and feel of a browser. Are we modelling on any particular one?

Well, if you can, take a look at netpositive on BeOS (look on inet to see screenshots if you need) or voyager from QNX RtP.
I think the browser should be lean and mean, and extra functions should be added using a plugin mechanism.
this way, you have the bare browser, and you can use 'spinoffs' to fit into it.

and I'm all for gcc or lcc usage. (actually, after playing around with lcc, I think that one is even better for c .. )

Why not just create the rendering engine (like Gecko) and let anyone else who wants to create a browser around it do so?

Well if the system was modular then the rendering, fetching, enviroment management, cacheing, queuing. plugin and 3rd-party-app vectoring sub-systems could be interchanged and developed separately.

Chris

- 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.

What is it with your obession with p0rting libraries, or more to the point, asking people to p0rt them for you?

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.

Please, let's not do a FRX again. It made good comedy though.

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.

I have to agree with you Paul. This project needs direction and competence if it's to get beyond idle chatter/opinions on an online forum.

Chris

- 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.

What is it with your obession with p0rting libraries, or more to the point, asking people to p0rt them for you?

I'm not asking for anything. I am pointing out that a port of something like STLport would aid no end in the development of a web-browser, especially if you borrow bits from something like Gecko.

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.

Please, let's not do a FRX again. It made good comedy though.

So are you saying that the whole project should be allowed to be a mish-mash without any form of direction, with people working on bits that others are working on and in the end everyong producing something which has glaring holes in?

Talk like that and you'll soon be working for Micros**t

Well, that's not strictly true. You can do objects in anything, but you'd have to bend the API so much that I wouldn't be happy calling it a DOM any more. A DOM implmentation in Java is child's play, and not much more work in C++. In C it would be a mammoth task.

I think C Front (Norcroft) would be up to doing a DOM implementation and an XML pa**er with HTML extensions (or full SGML if anyone was up to it!). It doesn't require namespaces, or even anything more than public inheritance really. But if you restrict yourself to Norcroft, you're restricting who can develop.

Remember that C++ is backwards compatible; you can write C inside a C++ API wrapper, or just plain C. And if you use something that can spit out AOF (that's both GCC and Norcroft, right?) you can link in assembler and fortran sections (though granted the mangled method names in C++ are a nuisance).

Waste processor time? I don't think so, it's just an extension to Wimp_Poll'ing with the OS. Call Wimp_Poll, decode reason code, perform internal upkeep, call Wimp_Poll etc. I'd suggest using the wimp message system. Either that or write your own threading library, which in itself will be fun.

My apologies I misunderstood your original post. I thought you meant coming off a wimp poll and going round all your modules to see what (if anything) had changed. Obviously you meant that the modules should generate a message across the wimp when done.

The vast majority of things can either be divided up easily (buffering for reading/writing sockets) or completes fast enough to be done in one poll cycle. The most obvious tricky part is multitasking redraw - and that needs a heavyweight architecture if it's going to be smoother than Browse. You could just write a helper class to queue many short function calls and execute them as and when, though hopefully that's not the simplest way of doing it.

I'm out of practice at writing big systems without threads, in case you couldn't tell!

Oh, and C++ would be nice because it supports exceptions. That's the easiest way to make sure most screwups only take down the minimum of code necessary and don't type=5 at every turn. In my opinion.

[Edited by ninj at 19:18, 22/4/2002]

[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]