I own my data, was Re: [Design] introduction and a few ideas.

[Aaron]

On Mon, 21 Oct 2002, petite_abeille wrote:
> Also, keep in mind that the data itself does _not_ belong to the
> application: it belong to the user. Making any data addressable through
> standard protocols make moving data in and out of the system a breeze.
> Which is a "good thing" as nobody want to be stuck in any particular
> system with its very own data buried under multiple layer of
> proprietary format.

Hear hear!  Huzzah!

I try various email clients all the time.  I will use one client for
awhile, then another, partly because I'm bored/curious and partly
because, in the words of the mutt developer, "All mail clients suck.
This one just sucks less."  www.mutt.org

I would not be so willing to try different clients, except for one
thing:  I run my own imap server, and I keep all my messages behind my
imap server.  So switching email clients for me is trivial, as long as a
client supports email.  Most people probably don't go so far for a
single desktp, although my impression is that some on this list do
almost that.  Certainly many people in campus/corporate environments do
exactly that, keeping all their email "up there" on the imap server.

--->>> Import/export is never an issue for me. <<<---

Which is nice, because import/export almost never works 100% correctly,
and even if import works, there is usually no export to go back the
other way.

I am looking forward to Chandler, if for no other reason than maybe it
will "suck less" as a mail client.

There are two ways to try a new application that might replace your
current application, and they differ mostly psychologically.

1. Casual.  "I'll try it for awhile, as long as I can back out of it."
This is probably the most common mindset when trying, say, a new email
client.  Many people may not even import their messages into a new
client, for various reasons.  You play around with it for awhile, with
no feeling of commitment and therefore no true assessment of what it
measn to live in the new app.  Even if you import your data, you don't
think of the app as *the* app for the time you're trying it.

The casual new user never really gets the full experience of the new
app, because they aren't committing their data or their daily work to
the new app.

2. Committed.
This involves using the app every minute of every day where you would
normally use the app, without reservation.  This is the only way to
really get a sense of whether the app is for you or not.

Since I store my messages in IMAP, I can simulate commitment to a new
client, since I'm confidant that my messages will survive in a form that
is usable in at least whatever I was most recently using.  Most
importantly, I'm not tempted to temporarily go back to my most recent
client when "something important" comes up; I just save messages as
usual, and I gain the experience of using the new app even during
"something important."

Oh, yeah, we're talking about Chandler design ... Chandler is going to
have its own notion of storage, I assume, and most people who end up
staying with it will probably import their messages into it and be done
with it.

However, you'll have all these cool views of your Chandler-stored
messages, and mail stored on IMAP servers will be second-class citizens
with respect to Chandler-views.

Why not design in an interface to IMAP (which is eminently searchable,
viewable, retrievable), so that data stored behind IMAP looks as if it's
a Chandler store?

You could do this directly, like so:

[ViewBuilder] --> [ImapInterface]
              --> [ChandlerStore]
              --> [POP]

so that whatever part of Chandler constructs views knows how to use
Chandler's IMAP code.  But then the ViewBuilder would have to understand
Imap, POP, WWW, etc, and I suspect that this design would quickly
devolve to "let's concentrate on the ChandlerStore and add in the others
when we can."

Or, you could do it more indirectly:

[ViewBuilder]--> [LDAP]--> [ImapInterface]
                       --> [ChandlerStore]
                       --> [POP]
                       --> [Outlook (it is, after all, programmable)]
                       --> [...]

(or something other than LDAP) Now ViewBuilder only needs to know about
the LDAP classes, and the protocol name and URI of any store to give you
the same view of your IMAP store as you could get for ChandlerStore.

And with that, Aaron gets to simulate commitment to Chandler.

It occurs to me, after looking back at the second design sketch, the
ViewBuilder-->LDAP/Whatever relationship could be elevated to
first-class feature status:  Try Chandler, you'll never have to import
your data.  You can use Chandler *and* whatever you're currently using,
simultaneously (or at least in close proximity).

New releases of Chandler would occasionally include new storage modules.

-- 
Aaron
aaron@justaaron.com
aaron@acm.org