Re: Another idea

Phil Frost wrote:

> I think you are missing some very important aspects of Unununium,
> assuming that by "the system" you mean "Unununium".
>
> Firstly, the persistence mechanism doesn't know anything about
> "objects". It wouldn't be orthogonal if it did, because it would then
> induce some dependencies on the structure of the data being persisted.
> It's true this is a poorly defined requirement, since assumptions like
> "it's in RAM" are made, but this is true of just about everything a
> computer can do.
>  
in data bases there usually are two different types of data objects. the 
permanent objects represent information which has to exist permanently, 
temporary objects contain information which is only needed to support a 
job only for a period of time or operations. which of both types an 
object is doesn't concern the persistence part. they both should be 
swapped in/out in background in the same manner to keep the system state 
persistent. temporary objects are not "just in RAM". temp objects don't 
have a great difference to perm objects. i think that there should at 
least be a way to distinguish both (at least an attribute). this would 
be useful for e.g. data backup, where temp objects are not of use.
one thing the persistence component *has* to know about is if a data 
object is "critical temporary". it's an idea by me to enhance data 
security. i don't know if this concept is in use anywhere at all. a 
critical temp object may never be stored persistently. an example: 
you're using pgp to sign or encrypt something. your private key is 
encrypted using a passphrase which is only known by you. you enter your 
passphrase to decode the private key. when not using such a "critical 
temporary" data object for this operation the orthogonal persistence 
most likely will swap your passphrase (applies to passwords too) out on 
your hard drive. but that's not all: even your _naked_ private key lies 
around on your hard drive defenceless, and could be read out by someone 
who might have stolen the notebook or just gains physical access to your 
box starting knoppix on it. even after destroying a data object there is 
no guarantee that it doesn't remain physically on the disk for a long 
time. this actually happenes with other operating systems too when 
swapping out memory - there are system calls to stop swapping for 
specific data. thus also for uuu: critical temp objects have to stay in 
RAM exclusively and should be ignored by the persistence.
> Thus, nothing is "owned" or has a "kind", as far as persistence goes.
> "object" is a word that gets thrown around too much in programming
> contexts, and it really has no meaning at all unless it's qualified with
> some sort of language, like "python object" or "ocaml object". Although
> Unununium has some code written in Python, the point is not to make
> PythonOS. Thus it is not safe to assume "objects" means "Python
> objects".
>  
i see your point. let's speak of data objects to avoid confusion.

> Secondly, "through the system" implies some sort of division that does
> not exist. There are no isolated address spaces, which means there is no
> kernel, which is what "the system" might imply.
>  
well, i didn't want to open the black box that much. you probably mean 
the part where i said, that the "system" automatically registers 
components of an application. that wouldn't be anything else than: when 
an application file reaches the box e.g. by downloading the app file a 
content type detector component automatically identifies the type as 
"application package" and calls the appropriate application manager 
component to construct the application object in the local persistent 
storage. while constructing this object this component also modifies the 
system configuration objects (registering components).
> Lastly, there is no filesystem, so there are no "directories".
> Persistence is orthogonal, remember? It's likely something, somewhere,
> will be accessible through some hierarchy, but your suggestions imply
> "everything is accessible through the one heirarchy". This is really
> traditional, and really insecure.
>  
i never said directories or files. i said these paths are "representing" 
data objects. the objects are not in the hierarchy. the hierarchy is 
semi-automatically generated by the component of uuu responsible for 
uniform data identification. it would use meta data and other properties 
to generate this tree. additionally the user might be able to personally 
modify this tree. this is only thought as one front end for the user 
which aims to be a replacement for uniform resource identifiers. if you 
download a file from the web. you won't get asked where to store it in 
the hierarchy or how to name it since it simply lands in the persistent 
storage, uniquely identified by it's properties. the semi-automatic 
virtual tree will automatically list it once or multiple in appropriate 
places (like search folders). the user should be free to modify his own 
structure and set personal rules how to represent data in this tree.
just imagine that you have printed many different formulars on which 
foot notes you automatically insert this path-"representation". it would 
be the quickest and easiest way to find a specific formular again if you 
need more printouts of that one you're holding in your hands.
of course there are other (and for most cases better) ways to identify 
data out of this persistent storage, like advanced search mechanisms and 
identification just by meta data, but this is only limited on data base 
storages and therefore won't work for many source of data. also a 
semi-automatic virtual hierarchy is nice to browse around and to seek 
something in a hierarchical way ;).
for other sources like the top level paths web, file and floppy the path 
will behave in the traditional way.
--
Stefan Mayrhofer (Pythagoras1)

e-mail: stefan.mayrhofer@xxxxxxxxx
jabber: pythagoras1@xxxxxxxxxxx
mobile: +43 650 990 20 81

Vienna University of Technology, e0526971