Re: Proposal for bookmarks/history database

[Peter Harvey <pah06 uow edu au>]

Magnus Therning wrote:

> On Tue, Nov 15, 2005 at 09:50:53AM +1100, Peter Harvey wrote:
>  
>
> > Database layout (warning: I am not a database person).
> > ------------------------------------------------------
> >
> > Each 'node' of information is identified by a unique integer. We store
> > the statement "node X belongs to a set Y" as "node X is a child of node
> > Y".
> >
> > table 'set'
> > int parent      # index on this field
> > int child
> >
> > table 'pages'
> > int id          # primary key
> > string url      # url
> > string title    # title from last visit
> > string icon     # icon from last visit
> > string btitle   # NULL if not bookmarked otherwise it's bookmark title
> > string bicon    # NULL if should default to icon
> > date visit      # date of visit
> >
> > table 'sites'
> > int id          # primary key
> > string name     # things like 'slashdot.org' or 'abc.com'
> >
> > table 'topics'
> > int id          # primary key
> > string title    # title of the topic
> >    
>
> Just to see if I understand what you mean:
>
> 1. set - table used to group things together
> 2. pages - table for storing history
> 3. sites - table of bookmarks
> 4. topics - table of topics
>  
Almost. The idea is that we have little clumps of data called 'nodes'. 
Each 'node' might be a topic clump, or a page clump, etc. In theory it 
can be more than one at the same time.

The 'set' table is used to link nodes together in parent-child-like 
relationships. Any child can have any number of parents, and vice-versa.
The 'pages' table contains all the page data. ie. visits to webpages, 
and bookmarks.
The 'topics' table contains all the topic data. ie. the topic name. :)
The 'sites' table is like the 'topics' table, except the nodes function 
like an auto-topic. The 'name' field is the name of a site, and all the 
child nodes are pages that you have visited at that site. This is to 
make it easier to browse your history by site. I will admit that I don't 
have the

> To put a site S in a topic T you add a row (T.id, S.id) to 'set', right?
> Won't 'sites' need a URL field as well? Or are you proposing coupling
> every site with a page? If you are, cleaning out history needs a little
> care, right?
>  
Hope that the text above explained. But anyway, the basic procedure for 
adding a history item is:
 int node = ephy_db_node_new ();
 ephy_db_set (node, EPHY_DB_PAGE_URL, url, EPHY_DB_PAGE_TITLE, title, 
..., -1);
 ephy_db_add_child (EPHY_DB_HISTORY, node);
ie. create the node, store page information in that node, mark it as a 
history item.

To make that a bookmark:
 ephy_db_add_child (EPHY_DB_BOOKMARKS, node);

To create a topic instead:
 int node = ephy_db_node_new();
 ephy_db_set (node, EPHY_DB_TOPIC_TITLE, title, -1);
 ephy_db_add_child (EPHY_DB_TOPICS, node);

Thanks to this little exercise I've realised I don't have a basic search 
function. :) Perhaps the correct way to add a history item is this:
 int node = ephy_db_node_new ();
 ephy_db_set (node, EPHY_DB_PAGE_URL, url, EPHY_DB_PAGE_TITLE, title, 
..., -1);
 char *sitename = extract_site_name (url);
 int sitenode = ephy_db_find (EPHY_DB_SITE_NAME, sitename, -1);
 if (sitenode == 0)
 {
    sitenode = ephy_db_node_new ();
    ephy_db_set (sitenode, EPHY_DB_SITE_NAME, sitename, -1);
    ephy_db_add_child (EPHY_DB_SITES, sitenode);
 }
 ephy_db_add_child (sitenode, node);

> Will the handling of hierarchical topics remain in the UI? (I.e. a topic
> with a name like "X->Y" will show up in the menu as an item X with a
> sub-item Y.)
>  
No. The automatic hierarchical code we have in place in CVS should 
handle almost all of your needs. I hope. :)

Regards,
Peter.