Hi Günther,
I'm a bit late on this one…
Le 30 mai 06 à 20:49, Günther Noack a écrit :
Am 30.05.2006 um 01:00 schrieb Quentin Mathé:
Yes, however I don't think it's a very wise choice to store
everything in files, because most file systems have bad
performance when you are dealing with huge number of files. I
don't really know what is the right choice for Grr. To take an
example, for a mail client (dealing with ten or hundred thousand
mails quite often) it's a better to store each mail folder or
account in a file and write a translator to present them as files
in File Manager or to other applications.
Bookmarks, contacts or feed articles could be serialized very
easily in one file and a simple translator may provide virtual
objects by mapping them to precise to XML nodes in the file
format (just supposing the serialization is done in XML here,
plain text, plist, binary could be better depending on the content).
In the current version of Grr, that's exactly what I do: On exit,
Grr serializes its list of Feeds into one single file. Every feed
also serializes its list of articles into the same file.
I don't want to keep this, because it turned out to be very slow on
startup and exit when using it for some weeks, because the file can
become very big.
ok. You may take an intermediate solution, storing each feed in a
file, but not each article. Eventually it could better to rely on a
small database like SQLlite.
If I understood your 'translator' concept right, it is about
creating "proxy" files representing the articles to make them
browsable and searchable in the file manager?
Yes, but it's not restricted to the file manager. It's about
decoupling the way the data is stored and how it is represented and
organized on the user side. In fact, real files should be represented
in the same way, with 'proxies' exported by a File System translator.
I've heard of applications using this (MS Etourage on OSX), but if
I understood it right, this is merely a hack to allow Spotlights
per-file indexing there.
Well, it depends. From another point of view, to have indexing based
on the storage structure doesn't always make sense, because you are
going to choose such structure for design and efficiency reasons
(this implies file system based solution won't always fit your needs
very well). Moreover your design choices in a program (how you model
the user representation on the programming side) may not match the
user representation on the UI side or only partially. This user
representation by conveying the semantic structure is usually closely
related to what should be indexed.
What's the advantage of storing everything in one big file? I know
that NSArray is faster than a file system (because things are
already in memory), but I wonder how many articles a user then
needs to look at to save time compared to the 'multiple files'
scenario.
Well, I don't know at how many articles, this choice becomes really
interesting.
To take an example, to work around Spotlight limitations, Apple Mail
is now saving each mail in a separate file (not anymore a file per
account) and this results in a really slow messages loading when you
open a mail folder or account for the first time (quite slower than
Panther version, even if this is surely enforced by my slow hard
disk). Another side effect is the time to backup my mails has
increased a lot, between 2x and 4x slower I think (600 MB spread over
several ten thousand files, before only over a few dozens of files).
Quentin.
--
Quentin Mathé
[EMAIL PROTECTED]
_______________________________________________
Etoile-dev mailing list
[email protected]
https://mail.gna.org/listinfo/etoile-dev
