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. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20080910/f4113f1b/attachment.pgp>
