From: nicolas.pouillard@gmail.com (Nicolas Pouillard)
Subject: [sup-talk] rethinking sup part ii
Date: Wed, 23 Jul 2008 19:40:35 +0200 [thread overview]
Message-ID: <1216834375-sup-1899@ausone.local> (raw)
In-Reply-To: <1216692061-sup-3543@entry>
Excerpts from William Morgan's message of Tue Jul 22 04:12:09 +0200 2008:
> Reformatted excerpts from Stephen Patterson's message of 2008-07-21:
> > So we'd then need a collection of custom client applications to search
> > and/or browse the index?
> >
> > This sounds quite a bit like the beagle project -
> > http://beagle-project.org/Main_Page
>
> Thanks for the pointer. It does sound quite similar. Having played with
> Beagle a bit, I think they key difference is that I'm envisioning STS as
> being the primary interface to your precious infos, whereas Beagle seems
> more of a supplemental index of data that's primarily handled by other
> apps.
>
> This has a couple implications, including who's responsible for storing
> the files (STS: STS; Beagle: you and your apps), and what the user
> experience looks like (Beagle: use Thunderbird, then call up Beagle for
> help; STS: browse everything through your client, starting with a
> search for label "inbox", and call up other applications for handling
> foreign mime types).
>
> If anything, Beagle is closer to Sup classic, and STS brings us closer
> to Gmail.
Another design choice, that could (and perhaps *should*) be made; is that
stored data don't change in the case of mails, IM..., only their labels and
children (threading) do.
Then, this makes even more differences, general file system indexers have an
harder task since, files change all the time this imply more complex data
structures that often provides worse complexity than one could wish.
Cheers,
--
Nicolas Pouillard aka Ertai
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20080723/4e09fbde/attachment.bin>
next prev parent reply other threads:[~2008-07-23 17:40 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-20 21:33 William Morgan
2008-07-20 23:28 ` Guillaume Quintard
2008-07-21 0:04 ` William Morgan
2008-07-21 5:43 ` Guillaume Quintard
2008-07-21 12:14 ` Peter Krenn
2008-07-21 15:22 ` William Morgan
2008-07-21 15:26 ` Stephen Patterson
2008-07-21 16:04 ` John Bent
2008-07-22 2:12 ` William Morgan
2008-07-23 17:40 ` Nicolas Pouillard [this message]
2008-07-23 22:26 ` William Morgan
2008-07-24 9:16 ` Nicolas Pouillard
2008-07-21 18:43 ` Lionel Ott
2008-07-23 8:45 ` Richard Heycock
2008-07-23 8:58 ` Nicolas Pouillard
2008-07-23 9:27 ` teroz
2008-07-23 21:41 ` Richard Heycock
2008-07-23 17:09 ` William Morgan
2008-07-25 12:11 ` Marcus Williams
2008-07-24 4:55 ` Guarded Identity
2008-07-24 9:21 ` Nicolas Pouillard
2008-07-25 16:00 ` William Morgan
2008-07-26 7:32 ` Guarded Identity
2008-07-25 7:18 ` William Morgan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1216834375-sup-1899@ausone.local \
--to=nicolas.pouillard@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox