← Back to team overview

tomdroid-dev team mailing list archive

Re: tomdroid's storage-redesign && what do we want to keep in the database as a note?


On Mon, Nov 16, 2009 at 9:17 PM, Olivier Bilodeau
<olivier@xxxxxxxxxxxxxxxxx> wrote:
> hi guys,
> Just working on reviewing some code for tomdroid and it got me thinking
> about something I would like to ask people with tomboy experience.
> Let me explain quickly.
> There is this hack we do right now in the storage-redesign branch[1] to
> re-create XML tags after we parse them in a note. The deal is we want to
> parse the xml tags except the ones in <note-content>..</note-content> so we
> store XML in our sqlite database for the note-content portion and parse it
> again on the fly when a Note is viewed.
> I _really_ find it disgusting, it looks like:
> String tag = "<";
> if (uri != null) {
>     if (uri.equals(NS_LINK)) {
>         tag += PREFIX_LINK+":";
>     } else if (uri.equals(NS_SIZE)) {
>         tag += PREFIX_SIZE+":";
>     }
> }
> tag += localName+">";
> xmlContent.append(tag);
> for open tags and close ones inside of a focused xml class.
> Now, (and here is where I need your experience), I was thinking about 2
> potentials solutions here (aside from the fact that we might just be
> misusing Java's XML parsing lib):

Android *must* have a standard XmlReader-type library for accessing
XML.  Hopefully it would be trivial to take Tomboy's note-parsing code
and rewrite it using the appropriate Android libraries.

> 1- store the whole note instead of just note-content in the database
> This way we won't lose addins metatags, full note encryption support will be
> possible, etc. Also, parsing the few lines of metadata on each load won't be
> that big of a penalty since its the note's content that is always the
> biggest.

I'm not sure what you mean here about add-ins metatags.  Can you
explain more?  Add-ins can't add new top-level tags to a Tomboy .note
file, but they can add new tags within the <note-content> element.

There is no full note encryption support in any client.  I think it's
a waste of time to design for something that doesn't yet exist.

When using web sync (which I really think will be the primary method
people use), you will have to parse note XML into JSON requests, and
JSON requests into note XML.  Tomboy has to do it and it's not fun,
and is an obvious place where bugs may show up.  If you assume that
most people will use web sync and not manual transfer of .note files,
then optimizing for that path makes sense to me.

Of course, my assumption could be wrong.

> 2- Forget about xml parsing just regexp out the note-content portion then
> parse the rest of the note. Or just use an xml lib that allows to extract
> part of the raw xml structure (or find the way to do it in Sax).

We use proper XML parsing to get to <note-content>, then we use
regular expressions (see the websync add-in) to remove the title from
there, because as I mentioned in my other email, the title is not part
of note-content in the JSON object.

We did all of this work of breaking the note up into a nice JSON
object so the only XML was pure content, in the hope that it would
make everything easier for new clients.  It definitely makes things
easier on the web, and I hoped it would also make things easier for

Of course, I may be totally misunderstanding what your issues are.

Sorry for the late reply, and also for not having a chance to actually
look at the Tomdroid code files under discussion,

Follow ups