On 5/28/06, Günther Noack <[EMAIL PROTECTED]> wrote:
I didn't work very much with BeOS, but I played around with it for a
while, so I'm not sure about mails, but the general principle in BeOS
was really exactly what we have been discussing in this thread: Most
"items" that would usually only be present inside their applications
were files there.
That worked, because they had metadata attached to their files, and
the file system automatically stored an index. (Just like spotlight,
right. Only much earlier. ;-))
Yes, indeed.
(snip)
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.
- we also want metadata (obviously structured too).
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
data, etc. Possibly in a very open way (structured files (plist?) +
directories ?) rather than binary...
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.
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
--
Nicolas Roard
"I love deadlines. I like the whooshing sound they make as they fly
by." -- Douglas Adams
_______________________________________________
Etoile-dev mailing list
[email protected]
https://mail.gna.org/listinfo/etoile-dev
