One boring day I came up with a great idea — then I forgot it. Another idea I came up with is for a Web browser based on loadable modules. It's similar to the 'plug-in' idea used by Shockwave and others, but much faster and more transparent.
All that has to be done, I figure, is to write a loader/unloader and a parser. The loader/unloader contains the frontend, detects which type of module(s) to load, and determines when to unload a module. Information is passed from the loader/unloader to the parser. The parser loads the module(s) specified by the loader/unloader and runs it on the document.
It works great on paper (or screen…), of course, but implemention is difficult. I figure the loader/unloader and the parser will be written in a high-speed, compiled language (like C or C++) and the modules will be written in a custom language. Another idea I had for modules would be Pliant, a language based on modules itself. This would work quite nicely, in fact. A pliant module could be written for module developers to write off of. The only problem, however, is that Pliant is new, slow, and not progressing rapidly. We may have to rely on our own language. Experienced language geeks, please help.
There are a few reasons why this is a good idea. First of, upgrades will be a heck of a lot easier. Secondly, due to the ease of upgrading and the focus on one module at a time, standards-compliant parsers will be easier to implement. Lastly, because this will cut down on the load time of the browser. And, of course, because I said so.
When the loader/unloader and parser are working, this Web site or someother 'site that I designate will be the official listing of all approved modules. So if you have a module, you'd better send the source to me for approval.
Modules will be written in a minimalistic interpreted language. The language will be updated with each release of the parser. Metadata in the language is a must, as so modules written for version 2.6 won't be run on version 1.23. Modules must also be portable. This means that a module written on my Linux'ed Laptop will run on the librarian's Macintosh and my mother's Windows95 machine, provided all these machines have mobb on it. The parser thus becomes a 'virtual machine'-type of program, with the module running in it's own environment. Hopefully this wont cause the same speed problems Java had.
As far as user interface goes, I figure on supporting both console and graphical user interfaces (CLI and GUI). The CLI version of the loader/unloader, CLoad, will be written in just ANSI C. The GUI version of the loader/unloader, GLoad, will have to be different for each platform. What toolkit is used is dependant on whom writes the first working version for that platform.
I've made a listing of some stuff for mobb to support. If you want anything else supported, just email mike@mike-burns.com with your suggestion. I'd suggest you get started on a module, but I haven't a finalized module language yet.
I had apparently heard of programming.
I continue to try to write my own browser — and in a modular fashion! — off and on. These days I'm going for more of a privsep plus document-focused UI approach. Also I know enough about programming now to say words that mean things.
I mention CLI
in here,
which I find fascinating: I've been under the impression that this was a
recent initialism, but apparently it goes back to the late 90s if not
earlier. Huh!