Le 28 mai 06 à 20:56, Nicolas Roard a écrit :
On 5/28/06, Günther Noack <[EMAIL PROTECTED]> wrote:
I think that in the long term all this will be available on OSX and
Windows too, again. Remember that it was originally also planned for
Windows Vista. And this means, that we'll probably have metadata
support on Linux and FreeBSD, too. So I think we should just build
metadata support into the Etoile file classes (a category for
NSFile?) and start writing applications that use this, so that we'll
be prepared when we get kernel-level support for it. :-)
Well, the way I see it, there's two things:
- we want "structured" files/data. Eg to take the person/beos case,
the informations should be in the file, not in the metadata. They were
in the metadata on beos simply because metadata provided an open way
of storing/accessing structured information.
Good point. These informations are attributes of person objects, but
not metadatas.
- we also want metadata (obviously structured too).
What do you mean by structured metata ?… A tree-like structure, not
just a key/value pairs list ?
For managing "structured" files, we use objects.
We can do that right now in GNUstep -- simply serialize your objects !
The plan for étoilé is to have CoreObject handles persistency -- eg
you'd work with a "CoreObject" and it will automatically save the
Yes, that's the plan but probably not the short term one.
data, etc. Possibly in a very open way (structured files (plist?) +
directories ?) rather than binary...
This is easier to implement. We may provide two solutions :
- plist for composite document or rudimentary database
- translator (bundle that exports application specific format in an
open way for the rest of the environment) in any other cases
Using CoreObject over default serialization highlights another
important point: what we _really_ want is not "simply" structured
files (after all, _any_ file format by definition is structured). What
we really want is a structured format that is _open_, readable by any
application. That was one of the really cool thing on the NewtonOS:
all data was saved in structured databases, but any application could
access/exploit easily any databases, which helped a lot to create
synergy among applications and create a really integrated environment.
Additionally, the way we serialize a CoreObject could possibly change
with backends -- we could save in binary, in files+directories scheme,
in .zip, in databases, or taking advantage of metadata in filesystems
that support them, etc. Metadata storage would depend on the backend,
but applications will not care, as they will simply use CoreObject.
That illustrates very well the whole point of CoreObject, we might
save the whole environment in a single Unix file or not, that won't
change involve any changes to Étoilé or Étoilé applications.
Btw, I'm thinking about re-writing the Grr RSS Reader so that it
stores feeds and articles as files and I don't need to implement all
this 'collection management' functionality. So this would simply
become a very lightweight NSDocument-based applications that is able
to open files of the Feed type and of the article type. Suggestions
are welcome. :-)
That would be a good "test application" to implement these
functionalities, indeed
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).
Quentin.
--
Quentin Mathé
[EMAIL PROTECTED]
_______________________________________________
Etoile-dev mailing list
[email protected]
https://mail.gna.org/listinfo/etoile-dev
