5 Sep
2011
5 Sep
'11
9:50 p.m.
On 09/05/2011 03:20 PM, Haru Mamburu wrote:
Thanks a lot,
I put the "resume feature" request into Jira. :-)
File system storage is implemented and now I'm precisely looking for the right way to
use XE in a kind of non-profit library project, where attachments could be from 1KB to
approx 1Gb in one piece. That is why I'm doing field test to avoid surprises in the
nearest future.
My first preliminary conclusion: it's worth to use XE in such a way, but for now
there are too many things go unusual way to use XE as is. I'm going to run project
anyway, so would be glad for futher cooperation to make file storage and big files
operation more seamless both for administrators and end-users.
Sure, we welcome as much feedback about the FS attachment storage as
possible. It's something quite new and worthy of improvements.
Kind regards
Dmitry
05 сентября 2011, 22:30 от Sergiu Dumitriu<sergiu(a)xwiki.com>om>:
On 09/04/2011 10:02 PM, Haru Mamburu wrote:
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
Hi!
By default, XWiki doesn't have "resume" ability for downloads. Is there any
way to turn it on? From the moment file system storage was implemented into XE it makes
sence.
It's not implemented yet, but it could easily be implemented yet if
there's demand for this feature.
And another question-idea:
On uploading big (all) files, XWiki creates hash for torrent, stores it together with
file.
On Download request - user gets torrent file and starts download.
Server side strats seeding and after download is complete - kills seeding process from
torrent-client.
Upload can be done almost the same way.
The question is:
Does existing XWiki functionality allow to implement such a upload-download technology?
Well, since it's Java, anything should be possible given the right
amount of time. Being Open Source, any feature can get implemented if
there's enough need for it, but for the moment there haven't been any
requests for such thing, so the best way to see this committed is to
come up with patches.