Extension Storage & Places DB Issues
Matty
data by an extension that I have been working on. It is fairly complex
and I've been trying to figure out the best solution for a while so I
thought I'd present it here.
The extension needs to store information attached to web pages.
However, it also needs to potentially attach a single piece of data to
multiple pages at once using regular expressions to match which it
applies to.
The previous version had an ability for the user to specify the location
of the configuration file to achieve a measure of roaming, and I am not
looking to regress the roaming capability.
Originally the extension used a text file but on adding new features
that necessitate a new format it is time to abandon that. The format is
essentially one relational table but I can't rule out wishing to add
other tables in future versions (though it is unlikely).
I had considered storing my data in an XML file, but the need to fully
rewrite each time creates scalability issues that I'm not comfortable
with, and I'd prefer a mechanism that would handle mid-stream crash for
me if possible.
I have also experimented with an SQLite database, which seems like a
good solution in terms of forward compatibility, reliability,
scalability and so on. However I am concerned with comments I have read
in the SQLite documentation regarding it not being reliable to place
such databases on NFS volumes. In particular the ability of a user to
specify the location of the database would seem to rule this solution
out.
The final idea that I had was to try to store the information inside
places.db. My thought here is to leave the roaming capability to the
synchronisation extensions that exist. I know of XMarks, though I don't
know if there are more localised sync extensions for people who disagree
with putting their data on a remote server.
So the questions are:
- Do sync extensions tend to support synchronising annotations? All,
some, none?
- Is it possible that my annotations will be lost by the "clear history"
function or similar?
- I have seen the following:
--
Matty
matty_i...@fastmail.fm
--
http://www.fastmail.fm - IMAP accessible web-mail
Matty
I've seen this in the annotations service.
EXPIRE_NEVER : Never expire. Must be explictly removed.
Can I assume this means that nothing will ever remove the place at all
because of this?
I was thinking that with regard to annotating a set of pages (by regular
expression) by annotating "about:blank" or something similar. Is this
likely to be problematic?
Are there any conflicts that I might have to worry about?
--
Matty
matty_i...@fastmail.fm
--
http://www.fastmail.fm - Or how I learned to stop worrying and
love email again
John J. Barton
> Hi, I am looking for opinions on possible solution to the storage of
> data by an extension that I have been working on. It is fairly complex
> and I've been trying to figure out the best solution for a while so I
> thought I'd present it here.
> The final idea that I had was to try to store the information inside
> places.db.
Firebug tried the places.db and got burnt. We went to a text file.
jjb
Matty
<johnj...@johnjbarton.com> wrote:
>> The final idea that I had was to try to store the information inside
>> places.db.
> Firebug tried the places.db and got burnt. We went to a text file.
Could you please elaborate on what the specific problems were? It would
be useful to know to what extent they apply to me.
--
Matty
matty_i...@fastmail.fm
--
http://www.fastmail.fm - Send your email first class
John J Barton
> On Tue, 05 Jan 2010 09:39 -0800, "John J. Barton"
> <johnj...@johnjbarton.com> wrote:
>
>>> The final idea that I had was to try to store the information inside
>>> places.db.
>> Firebug tried the places.db and got burnt. We went to a text file.
>
> Could you please elaborate on what the specific problems were? It would
> be useful to know to what extent they apply to me.
The issues are discussed here:
https://bugzilla.mozilla.org/show_bug.cgi?id=510984
The annotation service appears to be general purpose, but extensions
can't count on it after all.
See also
https://bugzilla.mozilla.org/show_bug.cgi?id=509106
jjb