RDF Todo List
This is a list of things that need to be done with the RDF back end
along with some details of how they should be done.
Making the state location independent
Berkeley DB is currently used to record bookmarks and
personalizations of sitemaps, etc.
There are at least two things broken with the current
We want to be able to use any kind of backing store (including
flat files) which can be anywhere.
- It assumes a berkeley DB.
- It assumes that the DB is local.
There is some special vocabulary that the browser recognizes
and some of this should be changed to use dublin core.
name to title
parent to section
Finish namespace handling in RDF parser.
Hiding html navigation
Many pages have a simple html based sitemap which should be
hidden if nav center is visible. The portion of html which
should be hidden should be placed within <navigation>...</navigation>
Need to hack the html parser (and/or layout engine) so that this portion of the html
gets thrown out if the navcenter is open.
Smarter History Clustering
Under history-by-date, if a container has more than N (=20?) immediate
children, it should be further sub-categorized.
Should consider getting rid of glhist.c and storing that data in some
rdf format. That will allow us to do away with hist2rdf.c, glhist.c
and also reduce memory footprint.
Need something in HT so that we can gather all the operations that have been
performed on a database. This can be used both for editing and by shack (to
transmit back all the operations to a server).
There should be two types of Smart Browsing Services --- folders containing
entries and html pages. The page services should also be invokable by
dragging a url onto them.
Persistent Client Store
Most of the backend work is done. Left to do :
- Security : checking to see whether the domain can read the database.
- Doing something about file size and lifetime (i.e., when does it
Need to finish this.
Reflect Cache as a data source.
Reflect Cookies as a data source.
It would be useful to have a new pane in navcenter corresponding to these
navigator internals (cache, cookies, what else)?
Create a data store which acts as a "scratch" workspace.
Create standalone lib with the following.
- Netlib and NSPR
- Expat XML parser
- RDF parser
- data sources for the RDF files, local files.
It should be possible to do a search in any collection of
documents (i.e., on any folder in NavCenter) --- bookmarks,
history, sitemaps, ...
It should be possible to do the search either in the body
of the document or only on the title (much less useful).
Searching the document might require significant network
activity, but this can be significantly reduced if the
document is in the cache. Maybe the rules for throwing
something out of the cache should be different for different
mime types? (i.e., text stays much longer than images,
preferably as long as history?)