Henning Hasemann wrote:
i think it's better not to use more than two different special
characters (eg / and >) which don't appear multiple, in combination or
as trailing or ending character (that means they can only be inside the
path). also paths should only represent objects no
actions/components/applications.
web/www.some_domain.foo/some_mp3_file.mp3>pcm
Nice idea but I find the "/" confusing. "web" is something that
interprets the string "www.some_domain.foo/some_mp3_file.mp3", which
also contains "/"s.
Im sure you intended this and it surely merges namespaces a bit more,
but it also makes a data stream (or object or whatever)
indistinguishable from an _address_.
it's just a representation, nothing else than an address. this address
uniquely identifies an object. in the actual case, the web path
web/www.some_domain.foo/some_mp3_file.mp3, the addressed objects aren't
alive yet. if a component tries to access the object behind this
address. the mp3 file gets downloaded in background. the detector
component detects that it is of type "mpeg2 audio layer 3" and than
hands over the data stream to the mpeg-component which construct a
_structured_ data object of type "mpeg2 audio layer 3" out of it. this
all happenes in background. the component trying to access the object
behind the address then gets this ready-to-use structured data object
handed over.
in the case web/www.some_domain.foo/some_mp3_file.mp3>pcm it's the same
except that the structured "mpeg2 audio layer 3" data object gets
transcoded into a "pcm" data object and then the requesting component
gets the "pcm" object handed over.
would be the representation of this mp3 file decoded to a pcm object.
Why object? Object sounds like "this is a static thing that is inside my
computer", thats nearly the unix/linux idea, or? Whould data coming over
a tcp-connection be an object to you?
no, i mean data objects which are completely parsed, structured and
ready-to-use for any component, not a linear stream of bits.
looks nice and simple, doesn't? i think this universal identifiers
should not be used to do anything else than modifying data like
encoding/decoding.
Depends on how you define encoding/decoding. A few point where Im not
sure if it whould say these all are encodings/decodings but where such
an universal identifier whould be nice
- (un)packing an archive
bla/foo/bar.zip addresses the zip object
bla/foo/bar.zip/blubb addresses an object based on the file blubb inside
bar.zip
unpacking happenes just by copying the blubb object into the local
persistent storage (or anywhere else)
- (un)crypting crypted data
decrypting:
bla/foo/moo addresses a "powerarchiver encrypted data" object
access the object behind bla/foo/moo>?
the storage (or detector component if it's just a file) knows that
there's a "powerarchiver encrypted data" object behind it. the
pae-component knows that it has to be decrypted before using and finally
hands over the resulting unencrypted data object, which will be
identified first, to the requester.
fyi: pae can encrypt any format therefore we use the "?" as destination
object type. it does convert into "unknown" and attempts auto detection
of the format after that.
if you want to decrypt into a specific format (that means decrypt into
something and convert after that) use this:
bla/foo/moo>xpm (convert the decrypted image - possibly jpg - into xpm)
crypting:
simply write whatever you want to bla/foo/encrypted.pae>pae
the data object gets converted into a "powerarchiver encrypted data" object
- interpreting an iso-file
identical to the zip case above.
- tunneling data through ssh
these addresses only address ready-to-use structured objects. what you
are trying to do is changing the way data gets processed into these
data objects, which happens on a lower level. i think this could be
managed by creating a custom object, which serves as base directory for
the new hierarchy. e.g. copy the "net" top-level object to "securenet"
and modify it's attributes using a "network object editing component" to
fit your needs.
therefore the result for that identifier should
always be an _object_ either representing a data steam, or structured
data. identifiers don't result into byte/bit streams. they should always
refer to an object created in the _system_ (that's what orthogonal means).
Maybe I didnt made myself clear.
I didnt want actually "pure" data streams without any properties. If we
get data that is seekable (for example a file or a hard disk) these
operations should surely be allowed, and so on.
I just talked (or wanted to) about data in general which is - in
programmers view - a Base class for structured data (I think you mean
seekable with that, or?) and streams and maybe other things.
just imagine a data object as something already parsed into a structure.
in mp3 objects you'll find id3 tags in the structure as also the left
and the right audio channels are structured into two attributes of the
object, which can be accessed directly in an object oriented way.
If you mean a python object (i.e. a class instance) youre right that
whould be the way to do it, but I didnt think about implementation
"details" at the moment.
And: why should it always result in something? I found it nice to route
data somewhere with telling the system to connect two points and let
data flow between them.
well it might be possible to introduce a raw data object. according to
my concept data can only flow when at least one component (part of an
application) is involved. to let data flow between two data objects you
need a component between it. imagine this as a pipe or hose: data can
only flow if there's at least one pump (component).
[...]
i bring this into detail when loading a docbook file on the
"documentation" server/workgroup:
net/documentation/products/foo3000/manual.xml
system automatically detects the source file type xml
creates a new xml (docbook) object containing the information (for editing)
I also thought about that.
Data has a mime-type and encodings/decodings can be registered for mime
types and will be automatically used.
net/documentation/products/foo3000/manual.xml>xml
would do the same
net/documentation/products/foo3000/manual.xml>pdf
system automatically detects the source file type xml
converts data to a pdf object (eg. for viewing)
In my world there is something like "xml2pdf" which has registered one
input stream for xml and one output stream for pdf. The system sees
xml-output > pdf-input and inserts xml2pdf between them to "correct" the
mismatch of mimetypes at this connection.
What a thing is pdf in your example? does it display pdf files?
net/documentation/products/foo3000/manual.xml>pdf simply accesses a pdf
data object. you can do what is possible with a pdf.
Or do you want to give the target data type?
Then you whouldnt be able to connect data as I mentioned earlier.
How whould you handle bidirectional data then?
(Terminals, net-connections, file read/write)
read and write are methods of the data objects. these methods are only
available if they are possible.
net/documentation/products/foo3000/manual.xml>pdf has no write method
since there is no pdf2docbook conversion method registered
home/pics/image1.bmp>png has read and write since conversion between
both formats is possible.
home/pics/image2.png>bmp here applies the same
If you track it down to just one-way and really just encoding/decoding
as a matter of changing the mime-type you got pipes with smart
encoding/decoding programs.
the direction of the data stream is bidirectional as far both directions
are supported:
home/pics/image1.bmp>png is bidirectional.
I thought about another thing: "programs" as we understand this word
today also have in- and output streams (and may even provide a
seek() function) how whould one call and connect those?
in my concept uuu components would access data only in an object
oriented way
[...]
now we assume i modified figure 1 (or not) and then export it as a nice png:
net/documentation/products/foo3000/figure1.png>png
the image program tells the system to save the object under that location
NOTE: all objects always belong to the system (orthogonal!)
the >png suffix tells the system that the object needs to be png first
the system converts the xpm object into a png object
system saves the png bitstream at this location.
Did I get you right that ">" doenst connect data-objects any more but
only indicates a suffix for "convert this data into that format"?
no, it means that the target address (the whole including >png)
represents a png data object. if
net/documentation/products/foo3000/figure1.png existed previously it
will be saved and/or converted into the format of the original file. if
it is new, then it won't be converted and therefore it will be png.
note: a data object can not change it's own type. conversion only works
on an other/new data object.
bad guys who want to (ab)use microsofts new (old) wmf security hole can
do this:
assuming the exploit-wmf is opened: export the object under the
following location:
mail/officeaccount/drafts/hello boss/greetings.jpg>wmf
the system would save the opened wmf-object as wmf-data stream as
attachment to the mail named "hello boss". the attachment will get the
name greetings.jpg but it contains wmf data (possibly with exploit).
I dont like that idea, because its an "implicit" change of data and the
">" suggests only a read.
if greetings.jpg was already there, the wmf object would be converted
into jpg. if the file is new the wmf object gets called greetings.jpg.
the >wmf part in this example is redundant since the opened data is
already a wmf object.
note: the file extension behind the dot has absolutely no effect on the
file format. so i suggest not to use extensions at all since the format
is identified by the object attributes.
--
Stefan Mayrhofer (Pythagoras1)
e-mail: stefan.mayrhofer@xxxxxxxxx
jabber: pythagoras1@xxxxxxxxxxx
mobile: +43 650 990 20 81
Vienna University of Technology, e0526971
| 
