Re: Online Desktop, Tomboy, and user storage

[Havoc Pennington <hp redhat com>]

Hi,

Sanford Armstrong wrote:
> Sync and Publish as distinct features concerns me; we don't want too
> many ways to do the same thing.  Maybe if Publish were equivalent to
> "mark this note public, sync if necessary"...

I agree here.

> I think this is a good idea, assuming it can be ready fairly quickly.
> If it's going to take a while for this feature to come online, I
> wonder if we would be better off forgetting about special WebDAV
> support for Tomboy at o.g.o.  Instead, we could focus on a proper HTTP
> API like you discuss below.  We could develop a sync addin for Tomboy
> that used this API as the backend, and distribute it to users as a
> separate installation.  This addin would be included in the next
> Tomboy dev cycle.

That is what I'm thinking right now; I looked through all the sync code 
and addin API, and I think it's a lot easier to hook in at the level of 
the sync addin interface, than to have a filesystem tree in the middle 
of things.

> >     I would envision that the available Tomboy note names and their
> >     revisions are in the Online Desktop Engine data model, and if
> >     the revision changes Tomboy would know to http/dav GET a new version.
> >     We would then also have a property of the note in the data model
> >     which was people looking at it or whatever.
>
> This sounds really cool.  In this situation, Tomboy would use DBUS to
> access the server via the Online Desktop Engine?  This would be easier
> than writing HTTP code.

I'm thinking of a kind of hybrid where the "metadata" is in the database 
and the ODE, and then the notes themselves are stored as files that are 
http put/get. The basic idea there is that shoving the notes in the 
database is a pain (mysql and hibernate are not great about handling 
large text fields), and it isn't super efficient to download them over 
XMPP either.

However, I'm not sure yet. Was going to start poking at the server side 
today.

> This brings up some other points that will have to be addressed
> eventually.  For instance, what umbrella will this web app live under?
>  Is it part of the Tomboy project?  The Online Desktop project?
> Something else?  Who maintains it?  Who makes the tough calls?  What
> about branding and visual identity?  The mockups I made were very
> Tomboy-centric because I wasn't thinking in terms of the Online
> Desktop at the time, but how will this fit into o.g.o?

My bottom-up suggestion would be online.gnome.org/tomboy/ so the same 
login cookie works (online.tomboy.org would require separate login), and 
because this is easier to implement given how the server is set up.

On branding, visual identity, and maintenance the possibilities are wide 
open. I figure getting something working will probably help us think 
about this.

If you made me guess today I'd say the clearest thing for users might be 
a "Tomboy, a feature of online.gnome.org" kind of brand positioning - 
the idea would be that online.gnome.org hosts a suite of various 
features. What's at mugshot.org/applications now might be another 
example, becoming "Linux applications at online.gnome.org" or something 
more creative.

For maintenance I doubt I can do a lot with it long-term to be honest, 
so I'd be looking for someone else to own the server project eventually.
First I'd say let's see if we can get something going and whether 
there's user interest, though.

And the server side may be essentially very small; a couple of jsp pages 
and a database table, and the rest of the work is shared with the larger 
online.gnome.org.

If the server side gets more complex, it will probably be because people 
are interested in hacking on it, in which case we have the maintenance 
problem solved ;-)

Anyway I'll start with just the black-and-white skeletal CSS that is on 
dogfood-online.gnome.org right now, and then if someone wants to come in 
and do a "Tomboy-fication" I am VERY happy to let someone else endure 
the hell that I find CSS to be...

> I don't know the answers to these, but I expect that the Tomboy
> project will want to be very involved, especially as the web app
> matures (think note editing).

The Tomboy team is very, very welcome to own this thing :-P I'm just 
trying to get it started and use Tomboy as a kind of case study to 
figure out all the problems we need to solve before a desktop app can be 
seamlessly integrated with a server side.

> How does the Publish feature interact with sync?  If I publish my
> note, then modify and decide to do a synchronize, are there separate
> versions available online?  Actually, I guess the more important
> scenario is when you already use sync.  Then when you Publish, what
> happens when you perform a sync from your other computer?  Do you get
> the last sync'd version of the note, or the last published version of
> the note?  Can you view both online?  These are the sort of scenarios
> that make me think Publish would be tricky to implement and confusing
> to the user.

I would think Publish is just sync of a single note. (I'm not sure 
anymore btw that I want to start with Publish because now that I'm 
thinking of doing a separate sync addin and avoiding the intermediate 
representation of the Tomboy data as a filesystem tree, I think it might 
be pretty easy to do all of sync.)

One footnote, I find the explicit sync menu item somewhat clunky; I 
would envision eventually just syncing in the background whenever stuff 
changes, at least as the default behavior once o.g.o connectivity is 
enabled, maybe with a check box if someone wanted to turn it off.

> Also keep in mind that Tomboy notes may be somewhat coupled to one
> another.  When you rename a note, all notes referencing the renamed
> note have their link text updated to reflect the new title.  This is
> one reason why we perform sync as a transaction (if all of your local
> updates don't get committed to the server, none of them do).

Ah, I didn't realize that. I'll try to keep that aspect.

> 1. User initiates sync.

(or it happens automatically in automatic mode)

> 2. Client requests manifest.xml from server to check for updates
> (maybe to save bandwidth, only requests manifest info for all updates
> since client's last sync revision).
> 3. Client requests that server locks for a new transaction.
> 4. Client requests each update specified in the manifest.xml (no need
> to specify revision number; server will always give the latest).

I'm wondering if I can skip manifest.xml and just keep that info in the 
database (of course it would be simple to generate the manifest.xml on 
the fly from the db info, but it looks like the need for the xml is in 
the filesystem sync addin, not in the sync addin interface)

Not sure about this yet. If this works out basically the Online Desktop 
Engine dbus API replaces the manifest.

Spent most of Friday and yesterday figuring out C# and writing 
DataModel.cs to talk to the Online Desktop Engine. I'll post some about 
that in a separate mail, then as I figure out more stuff I'll have more 
code to show.

Havoc