Phil Frost wrote:
It is used in the term "orthogonal persistence" because the code that is
responsible for persistence and that which is persisted are mutually
irrelevant. It doesn't have anything to do with "object ownership", if
such a thing is even defined.
i did not mean orthogonal persistence specifically. what i was trying to
say is that the code which handles/manages objects (that's what i meant
with "owned by the system") is orthogonal to the code which works on the
data in the object (the specific component/application). i'm trying to
express that all these different objects are not given to the
application/component. they get only access to it by the system. so the
system needs a uniform way to create data objects from files.
my idea is about giving the system the ability to create different kinds
of objects from the same file and to export different kinds of objects
into a given file format.
there are some things i need to extend on my concept:
in the docbook-example we probably want to import/export the file in the
following way:
net/documentation/products/foo3000/manual.xml>docbook
to get a docbook object out of the xml file which could be understood by
a nice-looking word processor. if the app saves the file as
net/documentation/products/foo3000/manual.xml>xml
the system would use the file for structured xml, but it wouldn't be
docbook anymore.
on the local system all paths already lead to (living!) objects. the
syntax can be the same but the suffix may only be used to transcode
objects. these top-level paths are:
home ... for the actual user's permanent objects
shared ... for shared permanent objects (between local users)
temp ... for the actual user's temporary objects
other important directories are:
home/applications ... user's application objects (see below)
home/config ... user's configuration objects
shared/applications ... system wide application objects (see below)
shared/config ... system wide configuration objects
temp/critical ... for temporary objects which are not permitted to
become swapped out for any reason (eg. passwords and encryption keys)
temp/shared ... for user-shared temporary objects
admins get access to the users' private directories using the
shared/username or temp/shared/username paths
other top-level paths also refer to objects, but they aren't living
(yet) since they are files in real:
floppy
disc ... cd/dvd drive
file ... misc. local file systems
net ... for a specific useful network file system (e.g. webdav or nfs)
web ... just replaces http://bla with web/bla
and several else (eg. protocol acronyms)
note that i don't use acronyms as far as possible since 'people cannot
memorize computer industry acronyms' (=pcmcia :)
that leads to an idea how to rip a track from an audio cd to ogg vorbis
just by copying an object:
source: disc/track01>oggvorbis (this refers to an instantly created ogg
vorbis object ripped from the track)
dest.: home/music/new/songtitle (put the >oggvorbis representation
behind it if you want, but it already is an object of the oggvorbis type)
also i suggest that the idea of having a 'current working directory'
should be discarded and only absolute paths should be used. therefore a
slash in front of paths aren't of use any more. relative file names
shouldn't be needed anymore since when changing the path of an object
all references to it should be automatically resolved by the system.
that's an advantage of a data base.
installing components/applications:
i think we get a consensus if we define application as a set of
components. therefore we could invent application objects which
represent enhancements to uuu. these application objects are packages
containing one or more uuu components which can be installed from e.g. a
web site just by copying it into the local storage:
source: web/someproject.org/files/greatnewpaintapp_1.3.4.app
dest.: shared/applications/greatnewpaintapp_1.3.4 (for all users, if admin)
or: home/applications/greatnewpaintapp_1.3.4 (for this user)
after putting the object there uuu internally registers all components
contained in the package into the system. these components will now be
available to the user whenever needed. components/applications can be
uninstalled just by deleting the application object
--
Stefan Mayrhofer (Pythagoras1)
e-mail: stefan.mayrhofer@xxxxxxxxx
jabber: pythagoras1@xxxxxxxxxxx
mobile: +43 650 990 20 81
Vienna University of Technology, e0526971
| 
