Mnemonic TODO list and other random ideas
General Info

Introduction
Screenshots
Mailing Lists and IRC
Alternative Browsers
Special Thanks

FAQ
Understanding Mnemonic
TODO list and ideas
Bug Reports


User Info

Download binaries
Platforms
Compiling Mnemonic
Other useful software


Developer Info

Core
Message modules
Library modules
Object modules
Coding Guidelines
Browse Source
Using CVS


View with any browser

Website questions to:
webmaster@mnemonic.org

Mnemonic questions to:
disc@mnemonic.org

 

Mail us your ideas!

Have interesting ideas yourself? Let us know. Send mail to disc@mnemonic.org.

TODO list (well-defined projects)

These are the projects that we know have to be worked on some day. Contact one of the mailing lists if you feel like implementing one of these. A rough estimate of the difficulty of each project is given.

Cookie handling (moderate)
Cookies should be parsed, and the client should pop up windows to ask whether cookies should be accepted. A module to store cookies and or accept/reject automatically should be written.

HTTP header information window (moderate)
It would be useful to have an information window that shows all header information that was retrieved from the server (eg. server name, date, expiration date etc.). A combination of a new message type being emitted by the http module and some code in the client module could achieve this.

Cache installation documentation (easy)
As we will not write our own disk cache software but instead rely on eg. WWWOFFLE to be installed, it is probably useful if setup of that cache software is described in a user-friendly way. Links to .deb and .rpm packages should be collected too.

Text-based interface (difficult)
As the layout library API has more or less been frozen, it may be interesting to write an ncurses-based client module to show off modularity. There is some demo code already in the lib-curseslayout module.

Handle animated GIF and other multi-image formats (moderate)
The lib-rasterimage library already reads animated GIF files, but lib-gtklayout will have to be extended for periodic redraw. One could of course argue that this is all evil and should be banned from the web anyway...

External helper module (easy to moderate)
There is already some code in oil-helpers to spawn helper programs for specific mime types that are not supported natively. This will have to be finished (the message code is mostly there already). Should probably be using the `run-mailcap' script as found in the `mime-support' Debian package.

Brain dump (not so well-defined projects)

This section lists ideas that have come up on the mnemonic mailing lists but did not immediately turn into well-defined concepts or actual source code. They may range from very simple things to pathetic day dreams. It's just a collection of random thoughts, really.

Info about HTML errors (moderate)
I had a thought. We should have an option in the preferences to turn on debugging. I mean none of the browser except lynx supports HTML debugging. This is one reason why there are so many bad pages. If netscape said "Hey your code is not valid at line ... because ... not allowed..." there would be fewer badly written pages. (Wouldn't be surprised if my pages are invalid)

I think therefore that if we just made human readable debugging and put them in a page so the user could read, they could alter their HTML code. Otherwise they just look at the screen and say hey it worked!

Mac port (long and difficult)
Mac folks seem to be very unsatisfied with Mozilla, mostly because of the UI issues. Therefore, if we're ever going to port Mnemonic to a non-Unix platform, MacOS should be the place to start.

Projects already taken

Secure HTTP (moderate to difficult): Steven
I guess it's clear we need this at some point. Should of course be based on an existing library.

Alpha channel blending code (easy to moderate): Max
To handle transparency and true alpha blending in lib-(gtk)layout, we need support in lib-rasterimage for it. This simply means being able to combine a given color with an image with alpha channel, or to combine two images. Can be written and tested independent of the other parts of mnemonic.

Technical issues and cleanup

Parser modules cleanup
The XML and CSS parsers should move to lib-dom as to make that library useful outside of mnemonic as well.

Elimination of int8_t and bounds checking
There are still a few places where we use int8_t and so on instead of something bigger. If we keep them, we should check for overflows.

TCP error code propagation
The msg_network_status message can contain progress update info as well fatal error codes. Most of the former are mnemonic status types (`looking up', `connecting') but the errors are mostly copies of errno.h. Remove the duplication of code for the latter.

Library separation on the website
It may be worthwhile to make separate pages for all the libraries which do not show the mnemonic framework so prominently. It is probably not very productive to also remove all dependence on the mnemonic-core module, but it should be more clear from the web pages that all lib modules only depend on mnemonic-core and can be used separately. Note that we could market mnemonic-core as an alternative to the bulky and C++ unfriendly libtool.

OIL framework module
Creation of an OIL module is rather complicated. Much work is duplicated (eg. thread startup/shutdown, listening to stop messages, thread-safe memory management and so on). Put this in a separate base module. As a result, all current OILs will become very small. Think of a better way to organise them.