On Thu, 2005-11-17 at 12:46 +1100, Peter Harvey wrote: > I should explain my thinking a bit more. My initial vision wasn't to use > SQLite. It was just to replace the custom EphyNode structures with > instances of g_hash_table. In my mind, a bookmark or history record or a > topic is just a hashtable like: > Then the idea of using SQLite was introduced (others were aleady working > on it). I just thought "what's the most efficient way to represent these > little bundles of information in a database?". Ah, yes, we have completely different mentalities! I was thinking of turning Epiphany into a web browser which uses SQL all over the place. So, if I understand correctly, you're using SQLite to benefit from its efficiency as a persistent hashtable with a fixed upper-bound memory footprint. > d. An extension would just have to register a new 'set of fields' which > we would then turn into a table. It may also register a 'global' node > if it so desires so that sets of nodes it creates can be easily > found. This isn't required though. A 'bookmark thumbnail browser' > extension might just add a 'thumbnail' fields and then set those > fields for nodes which are children of the 'bookmarks' node in the > globals table. I recommend putting all metadata into a single table (as galeon-sqlite does), since it's WAY, WAY simpler. As for more complex stuff: Imagine being me, an SQL-proficient extension writer. I see this API and I think, "okay, I can add/remove bookmarks/topics, link them to each other, and query history". I want to do something more complex: say, make another table and join Epiphany's bookmarks list against it. I can either: (1) learn the EphyDb API, or (2) create my own database in ~/.gnome2/epiphany/extensions/my-extension.db. Then the smallest amount of EphyDb code I'd need to get data from Epiphany that I can use to query my own database. Then I can use SQL to do anything -- for instance, NATURAL JOINs with other tables in my database. Whenever I want to JOIN against something in Epiphany, I'll just query Epiphany, and use the IDs it gives me to query against my own database. What can (1) do for me that (2) can't? Nothing. In some cases (2) will even be faster, and it will certainly be easier for me to program my extension, since I already understand all the concepts. The only problem I have is learning enough of the EphyDb API to circumvent it. I just don't see what EphyDb has to offer me, the extension author. The more time you spend developing an API for me, the more time I'll spend figuring out the workaround. > Most extensions would need only basic queries I believe. Depends on the extension author, I suppose. I thought you were using SQLite for the "SQL" part, instead of the "ite" :). > I appreciate the blasting. :) Just worried that I'm being too stubborn. > I will admit that if we go down the route of completely separate > "topics" tables and "bookmarks" tables and "bookmark_topics" tables and > the like, I *don't* want to be the one to write it. :) I'd guess that's because you're not comfortable with SQL; it seems like a lot less work to me. But to each his own. To be fair, EphyDb *could* make it simple to attach a field or two to history or bookmark items, and that could work okay. But when you start talking about adding 'globals' and making new tables, I know I'll be looking for a workaround when I write my extensions, because I see no reason to learn that API. In the long run, I can see that we started off with vastly different mentalities. Neither is right or wrong; I don't know how much I can help you with your implementation, beyond suggesting that you shouldn't really worry about extensions too much. -- Adam Hooper <adamh densi com>
Attachment:
signature.asc
Description: This is a digitally signed message part