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 ).
