Re: Browser Bookmarks Menu (Gnome Applet) 0.2

[Peter Harvey <pah06 uow edu au>]

On Mon, 2004-11-01 at 23:42 -0500, Adam Hooper wrote:
> On Tue, 2004-11-02 at 10:21 +1100, Peter Harvey wrote:
> > Integration with e-d-s or similar would be perfect. Integrating with
> > e-d-s might cause problems (if people don't want to use Evolution, why
> > must people use e-d-s just to get bookmarks in Epiphany?).
> 
> e-d-s isn't only for Evolution. It's badly-named, but it's intended to
> be for all of GNOME (including, say, IM applications). So the question
> then becomes, "Why must people use GNOME just to get bookmarks in
> Epiphany?" And the answer is, IMO, "Who cares? Everyone who uses
> Epiphany uses GNOME anyway."
> 
> (I'm a big fan of dependency, the oft-misconstrued reason open-source
> works.)

Sounds fair. I think that starting writing this outside e-d-s (with a
view to merging later) might be the best bet.

> > If we were to write a CORBA server we would also need to document the
> > concept of 'what is a bookmark' and 'what is a topic'. One or both of
> > the following would have to take place:
> >       * All users accepting 'topics' in place of folders.
> >       * Introducing code to allow 'subtopics'. IMHO if topic A has
> >         'subtopic' B, then all bookmarks that belong to B must belong to
> >         A. Nothing more restrictive than that.
> 
> Well, the nice thing about this proposed idea is that Epiphany bookmarks
> can easily be replaced by an extension. So I don't think *all* users
> would have to accept 'topics'. If they didn't, they could use a
> different 'bookmarks' extension which emulates Firefox's; they wouldn't
> be able to take advantage of the integration GNOME offers.

You might be saying here - we can write an Epiphany extension which
accesses Firefox's bookmarks directly. But also you might be saying - we
can write a CORBA server which accesses Firefox's bookmarks directly and
provides them to any application. This would be more interesting I
think, especially for e-d-s.

The problem is that each bookmark storage system should present the same
concepts to a client application. This is much the same as 'each
implementation of java.lang.* or libc should behave the same, regardless
of what is under the hood'. They may have their own little quirks, but
should be roughly the same.

I think generalising the bookmarks system and saying 'it will be a
directed acyclic graph, where each node can be a topic and/or a
bookmark' would work, with 'each bookmark/topic belongs to each topic in
it's ancestry'. This admits both Epiphany style systems, user-defined
hierarchical systems like Firefox/Galeon, and many things in-between. I
have attached a possible IDL.

> If we wanted the CORBA server to be more widely adopted... bah, can't
> that wait 'til after we have something functional? ;)
> 
> Wish I weren't swamped with homework these days. I'd love to hack at
> something like this to learn what the heck CORBA does (or even what it
> stands for).

Heh, I've only dabbled in CORBA myself. It's object-oriented gone mad.
Very, very flexible. For that reason I'd recommend writing something
like this in C (where OO support is also insane, but flexible).

/* Each node can have associated with it any type-data pair.
   You can obtain a list of nodes by type, or by parent, or by child.
   You can add and remove links, and get and set data. */

const string BookmarksTopic = "application/x-topic-name";
const string BookmarksUrl = "application/x-url";
const string BookmarksSubstitution = "application/x-smart-url";

typedef long Node;
typedef sequence<Node> NodeSeq;

interface Bookmarks
{
  Node addNode();
  boolean removeNode(in Node node);
  
  NodeSeq getNodes ();
  NodeSeq getNodesByType (in string type);
  NodeSeq getNodesByParent (in Node node);
  NodeSeq getNodesByChild (in Node node);
  
  boolean addLink (in Node parent, in Node child);
  boolean removeLink (in Node parent, in Node child);
    
  string getData (in Node node, in string type);
  boolean setData (in Node node, in string type, in string data);
};