If rushed for time - read the examples at the end and you get a good
idea of where this goes.
Well, depite a lot of work the metadata situation is getting quite
messy and in the honoured tradition of Whiterose - if it's messy rip
it all up and start again. I don't think we have much of an investment
of code in the new metadata system anyway.
Well, we have the metadata spec - and we want/need to encode some of
this into keys to avoid indirect lookups. So can we put keys with
metadata commands into Redirects etc? Messy.
What do we want? In the end we want to return data and
true-metadata. Where true-metadata is what the rest of the world
thinks of metadata - e.g. Dublin Core stuff not Redirects and the
like. Since we've used metadata for pretty much everything under the
sun so far we need a new term: and I'm going to use "document meta
information" (DMI) for no very good reason except I need something
(and we get a new TLA).
In order to get the document we need a key, keytype and decryption
key. The key encodes the keytype in the last two bytes anyway. So we
have a few functions to get documents:
KSK("/some/string")
CHK(big-number, decrypt key)
...
etc. Thinking in a good OO way these can return document objects which
can be queried for an FCP key (which is the binary routing key) and
know how to decrypt them.
Now Redirect can be defined as a function that returns a document
object, as can DateRedirect (it makes up the string and returns
KSK(string)).
Now, in order to support SplitFiles we need something higher. Let's
call it a task object and say the default task object takes a document
object and requests it, but the split file function can accept a load
of document objects and so on and returns a task object.
SplitFile(CHK (aabbccdeee, sdasdsa), CHK (aasdasdew, defdsfsd), ...)
We can now model requests like:
Request (CHK (aabbccddee, ffgghh), CHK (iijjaafdf, asdaskj))
so we have get the data from the first CHK and the DMI from the
second. No reason we can't say that if the decryption key on the
second CHK isn't given it defaults to the last key given (so we can
omit the second key for space)
We can also say that if no DMI document is given it looks for DMI (if
any) in the metadata section of the data document.
Request (SSK (aabbccddee, DBR (86500, "site/index-"))
DBR is DateRedirect and we spec the increment and Predate - it can use
defaults for the other values. It makes sense if DBR returns a
string. Could do:
Request (KSK (DBR (86500, "mysite/index-"))
and so on.
In the real world
-----------------
Well, we need this in keys:
freenet:SSK(aabbccddee,DBR(86500,site/index-))
freenet:KSK(DBR(86500,mysite/index-))
By RFC2396, "(" and ")" are unreserved.
Now we need the some way to do the browser hack of mapfiles. So we
keep the system of document names. In the metadata section of
documents there is a series of name-function pairs. The pair without a
name is the default:
=CONT(0,5675)
page2.html=freenet:CHK(aabbccddee,ffgghh)
page2a.html=freenet:CHK(aabbccddee,ffgghh)//p2
image1.png=CONT(5676,1243)
image2.png=CONT(6920,1452)
The CONT function specifies a range of the data of the current
document as (start offset, length) in bytes. This means you can have
multiple files in the same document (as with the images above). This
can save a lot of requests for small files. Also note the 2 files in
the same document with page2.html and page2a.html with the "//" and
docname.
You know how we said that if a DMI document isn't given we could
assume it was in the metadata of the data document? Well, now we can
say that it's in the document_name+".DMI" section of the data
document.
Example
-------
An MP3:
We put the DMI together in a file like this:
Author=Someone
Title=Something
Album=Whatever
Filename=Someone-Something.mp3
Content-Type=audio/mp3
In the metadata section of that document:
=CONT(0,67)
and puts the MP3 in a file and in the metadata section of that document:
=CONT(0,1034334531)
You then publish the key:
freenet:CHK(aabbccddeeff,hhggii),CHK(ttyyddggeegg,ddssasfg)
Now the client pulls in the document like the key read (in current layout):
freenet:CHK at aabbccddeeff,hhggii
and
freenet:CHK at ttyyddggeegg,ddssasfg
It parses the default section of the DMI document and parses the DMI.
It pulls out the default section of the data document and saves it to
disk as Someone-Something.mp3. (just an example, I'm not specing the
DMI).
A Web Site:
Put all the icons in a document together and in the metadata section:
icon1.png=CONT(0,567)
icon2.png=CONT(568,1045)
icon3.png=CONT(1613,6745)
icon1.png.metadata=CONT(8359,34)
icon2.png.metadata=CONT(8359,34)
icon3.png.metadata=CONT(8359,34)
and insert as a CHK
Then make up the master document:
=CONT(0,3456)
.metadata=CONT(4481,21)
icon1.png=freenet:CHK(aabbccddeeff,hhggii)//icon1.png
icon2.png=freenet:CHK(aabbccddeeff,hhggii)//icon2.png
icon3.png=freenet:CHK(aabbccddeeff,hhggii)//icon3.png
stylesheet.css=CONT(3456,1024)
content1.html=CHK(ddeeffssgg,ffddfss)
content1.html.metadata=CONT(4481,21)
and insert as a CHK
distribute the key:
freenet:SSK(ddeeffgghhjj,DBR(86500,"mysite-"))//
This will lookup do a DataRedirect with increment 86500 and Predate of
"mysite-" and lookup, for example (in current URI)
freenet:SSK at ddeeffgghhjj/mysite-456564436
and get a document which you insert every day:
=freenet:CHK(ttgghhyytt,dsdfd)
which is a redirect to the master document (which may change every
day). From there it loads the default section (a HTML document) and
the metadata section ".metadata" which contains something general
like: Content-Type=text/html
The web page can refernce icon1.png by the "//icon1.png" means, which
causes a lookup for an icon1.png section in the master document which
redirects to the images document... You get the picture.
This is a long post for me. This metadata system at least looks clean
for the moment. It might need a Version header replacement.
AGL
--
I never let my schooling get in the way of my education.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 240 bytes
Desc: not available
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20010405/dd0b8b4c/attachment.pgp>
