Re: Online Desktop, Tomboy, and user storage

["Sanford Armstrong" <sanfordarmstrong gmail com>]

On 8/2/07, Havoc Pennington <hp redhat com> wrote:
>     This may not really matter for Tomboy, private-only DAV might be
>     fine, and any public note sharing would be via regular http/web-ui.

Absolutely.  We never intended for WebDAV to be the de facto way to
store/sync/share Tomboy notes.  It just happens to be the easiest
network file system (via wdfs/FUSE) for us to interact with.  Clearly
a real sync server is the superior choice, with client/server
interaction via an HTTP API, or XML-RPC, or whatever makes sense.  The
only reason I'm still talking about WebDAV is out of concern for the
current release cycle, especially now that we're in feature freeze.
:-)

>   - it should be possible to globally say "put my stuff on
>     online.gnome.org" or "put my stuff on myserver.mydomain" instead of
>     configuring each app and logging in separately for each app.
>
> Anyway, these config and auth issues need solving even for plain sync to
> work "out of the box" and nicely.

+1!

> Second, to get the cooler features beyond sync, we have to go beyond
> getting DAV working smoothly.
>
>   - the web UI. I think we should be able to have a Publish button
>     in Tomboy to make a note public for sharing, and also
>     you should be able to browse your own notes online.

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"...

>     This means at minimum a "dedicated" DAV share for Tomboy,
>     rather than having just a generic WebDAV server that a variety of
>     different apps use, some for "dotfile" type stuff and some for
>     human-readable stuff. The DAV share for Tomboy should be dedicated
>     so it isn't mixed with your human-readable DAV share, and so the
>     server can understand its format and list/display Tomboy notes.

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.

>     The point isn't that we shouldn't use DAV; it doesn't matter. The
>     point is that the server can't be "just a DAV server," it has to
>     understand the data, if we get beyond sync. DAV is an
>     implementation detail of a custom Tomboy server, as soon as we do
>     more than sync.

Agreed.  Supporting WebDAV sync now sets up recurring cost down the
line, as we move away from a client-driven sync implementation (but
still have to maintain code that manages the DAV share).

>     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.

> All this said I have to figure out where to start hacking first ;-) so I
> was thinking of doing the custom Tomboy store on the server, plus a
> public/private flag for each note stored in the database, and a simple
> web page that lists your notes (filtering out private ones if someone
> other than you views it).

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?

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).

> Then the first API to the custom Tomboy store on the server could be
> "upload note with a given name," and would be used by a Tomboy add-in
> that adds a Publish menu item and just uploads the note. (This isn't
> sync - it just shoves a single note on the server, and never downloads
> notes.)

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.

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).

> The second server API could be a dedicated DAV root that implements the
> Tomboy sync layout, and doesn't allow anything other than Tomboy notes
> in that layout to be uploaded or downloaded.
>
> When a Tomboy note is uploaded to the DAV share, we would also create
> the Tomboy note metadata in the database with e.g. the public/private
> flag or a list of users who would have access rights to view it.

Sounds great if we stick with DAV.

> If this is how it works, I do wonder if it is easier to write the
> note-list-to-filesystem-tree code on the server side, or to write a
> different sync plugin for the client side that does not convert to a
> filesystem tree or mess with FUSE as an intermediate step but instead
> just talks to the server in terms of note names and revisions.

Yes, that would be fantastic.  In fact, the client would not
necessarily have to communicate any revisions to the server.  I see
the workflow as something like this:

1. User initiates sync.
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).
5. Client sends local updates to server.
6. Client requests that server commit current transaction; new
revision number returned on a successful commit.
7. If commit was successful, client sets new revision number on all
notes that had updates sent to the server (used later to check for
modifications, etc).
8. Rinse, repeat.


Sorry for the delayed response; work's been keeping me busy.  I'm back now.  :-)

Sandy