Matthew Toseland a ?crit :
> On Wednesday 10 September 2008 18:42, pmpp wrote:
>> Matthew Toseland a ?crit :
>>> On Saturday 06 September 2008 23:21, pmpp wrote:
>>>
>>>> hi, i have made a small cifs experiment based on alfresco jlan-4.0 (
> gpl )
>>>> pure java on non windows , 2 jni dll on w32/64known problem: cifs IO
> will block on file copy/seeking till chk got at 100%
>>>> by freenet because no pseudo-randomaccessfile access to current download
> is
>>>> available with fcp.
>>>>
>>> Nice! Any filesystem interface is going to have the last problem. It's not
>>> something we can easily fix: we really don't want to fetch stuff from the
>>> beginning, because then the later parts will fall out first. A plugin for
>>> Explorer (etc) to show progress would be a possibility.
>>>
>>> ------------------------------------------------------------------------
>> Thanks for you interest.
>> - imho plugin to show progress is not allowed at cifs protocol level
>> and is completely useless in multimedia appliance.
>> - You said "because then the later parts will fall out first " :
>> not sure , nowadays "files" are rarely fetch "from" the beginning .
>> especially with binary data container like mpeg
>> audio/avi/quicktime/matroska : these streams are indexed to allow
>> seeking. so application open a few headers blocks then jump straight to
>> the end of file to check bounds , and after it's a complex matter of
>> random access and prebuffering in the middle.
>> please note that in advanced video compression schemes, losing data (
>> not keyframe ) in input stream is tolerated.
>>
>> -"easily fix" why fixing ? If some don't want data to be random
>> fetchable : why not precise it in metadata ? as this type of access
>> make sense only for indexed uncompressed streamable binary structure and
>> then allow another splitfileType (eg with compression off by default ,
>> and FEC at user discretion , dedicated to random streaming of (volatile,
>> cause unpopular in 2 months ) multimedia crap ? ,
>> I already did a raf experiment on <16meg chk, it was usefull to add
>> such a type because things won't broke outside the testing code/node.
>>
>> Freenet at first glance seems to be a distributed remote storage, it
>> would be nice to have some concepts of a real useable storage device in
>> it. even if i know its basicly only a distributed unreliable lru cache (
>> I did same experiment in the past with chained squid and a samba plugin
>> after reading this
>> http://www.squid-cache.org/mail-archive/squid-dev/200002/0002.html ).
>
> Most of the time when somebody reads the file they will read it sequentially,
> because either:
> 1) They want to watch the movie/play the song from the beginning to the end,
> or
> 2) They want to copy it to another medium.
>
> IMHO different parts of a file falling out at different rates is
> unacceptable.
> The whole file should either survive or not. And of course for old/unpopular
> files, it may take a very long time to fetch the file: the download queue is
> the correct metaphor here, not the instantly accessible storage medium.
>
>
> ------------------------------------------------------------------------
Sorry maybe misunderstanding, I didn't mean to modify the way download
queue work and then fetch data from freenet sequentially. I was just
thinking about to give an FCP option allowing client access to the block
currently pointed by a pseudo-randomaccessfile ( let say a 1mo buffer
forward bounding a long pointer ) as soon as possible when it's
available from node. That will be very appropriate especially when
nearly all buckets are already in cache/datastore.
