> On Sun, 16 Mar 2003 15:25:06 -0800 Ian Clarke <ian at locut.us> wrote:
> If we ever get Freenet radio, then live Freenet streams will
> definitely want to delete old blocks to conserve space.
It just occurred to me that this problem is similar to (in limited ways) to that
of sending different types of data over the non-Freenet part of the Internet.
How to handle different types of data?
The two obvious ways that it's handled there are mime types and protocols.
Mime Types {
If a file's mime type is video/x-ms-asf, for example, then my the application
I'm using to receive it knows that the content is "streaming" and that it should
be normally deleted right after receiving it, that it wasn't intended to be
saved. But I still have the option of saving it, if my application has that
functionality built in.
Fproxy can already handle mime types.
}
Protocols {
Client and server agree on how to handle communications (HTTP, HTTPS, FTP, etc)
and implicit in this is some knowledge of what the contents of the communication
are and how it should be handled.
Freenet doesn't have "protocols" per se, but it does have keys. Could streaming
media simply be encoded using a new key type? Or some other indicator built in
to the URL?
}
Something I'm not clear on, could someone please clear this up? Just what,
exactly, can a node presently tell about the data in the data store? Can it
tell what key or key type it belongs to? Can it tell what node sent it, once
it's in the datastore? Can it tell what discrete chunks are members of the same
file? So on.
(It would make sense that the last question would be answered yes, lest how do
you put them back together when they arrive at the destination node? But just
to make sure...)
-todd
_______________________________________________
devl mailing list
devl at freenetproject.org
http://hawk.freenetproject.org:8080/cgi-bin/mailman/listinfo/devl