Re: Online Desktop, Tomboy, and user storage


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 so the same login cookie works ( 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" kind of brand positioning - the idea would be that hosts a suite of various features. What's at now might be another example, becoming "Linux applications at" 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

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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]