On Tue, Jul 20, 2010 at 7:19 PM, Max Semenik wrote:
> There's also Flash that can do it, however it's being ignored due
> to its proprietary nature.
May we drop our ideological concerns and implement multiple ways of
uploading, including Flash and Java applets?
--vvv
___
On Wed, Jul 21, 2010 at 2:05 PM, Aryeh Gregor
wrote:
> This is the right place to bring it up:
>
> http://lists.w3.org/Archives/Public/public-webapps/
>
> I think the right API change would be to just allow slicing a Blob up
> into other Blobs by byte range. It should be simple to both spec and
>
On Wed, Jul 21, 2010 at 12:51 PM, Neil Kandalgaonkar
wrote:
> That's what I said in the very next paragraph. :)
>
> I just wanted to clarify that yes, we do have native chunking in some
> browsers; no, it's not adequate for very large media files.
Yeah, I was just confused because I thought I sai
On 7/21/10 8:16 AM, Aryeh Gregor wrote:
>> So, as you can see, we do have a form of BLOB access.
>
> But only by reading the whole file into memory, right? That doesn't
> adequately address the use-case we're discussing in this thread
> (uploading files> 100 MB in chunks).
That's what I said in
On 07/20/2010 10:08 PM, Tim Starling wrote:
> Firefogg support has been moved out to an extension, and that
> extension was not complete last time I checked. There was chunked
> upload support in the API, but it was Firefogg-specific, no
> client-neutral protocol has been proposed. The Firefogg chu
On 07/20/2010 10:24 PM, Tim Starling wrote:
> The problem is just that increasing the limits in our main Squid and
> Apache pool would create DoS vulnerabilities, including the prospect
> of "accidental DoS". We could offer this service via another domain
> name, with a specially-configured webserv
On Wed, Jul 21, 2010 at 11:19 AM, Mark A. Hershberger
wrote:
> Could you point me to the specs that the html5 browsers are using?
> Would it be possible to just make Firefogg mimic this same protocol for
> pre-html5 Firefox?
The relevant spec is here:
http://www.w3.org/TR/FileAPI/
Firefox 3.6
Michael Dale writes:
> * Modern html5 browsers are starting to be able to natively split files
> up into chunks and do separate 1 meg xhr posts. Firefogg extension does
> something similar with extension javascript.
Could you point me to the specs that the html5 browsers are using?
Would it be
On Wed, Jul 21, 2010 at 12:31 AM, Neil Kandalgaonkar
wrote:
> Here's a demo which implements an EXIF reader for JPEGs in Javascript,
> which reads the file as a stream of bytes.
>
> http://demos.hacks.mozilla.org/openweb/FileAPI/
>
> So, as you can see, we do have a form of BLOB access.
But onl
Tim Starling wrote:
> The problem is just that increasing the limits in our main Squid and
> Apache pool would create DoS vulnerabilities, including the prospect
> of "accidental DoS". We could offer this service via another domain
> name, with a specially-configured webserver, and a higher level o
On 20 July 2010 17:15, Daniel Kinzler wrote:
> It appears to be the only good solution for really large files. Anything with
> a
> progress bar requires client side support.
Chrome/Chromium has an upload progress indicator, and it's excellent.
Really the best browser to use for uploading big s
On 7/20/10 8:08 PM, Tim Starling wrote:
> The Firefogg chunking
> protocol itself is poorly thought-out and buggy, it's not the sort of
> thing you'd want to use by choice, with a non-Firefogg client.
What in your view would a better version look like?
The PLupload protocol seems quite similar.
On 7/20/10 6:34 PM, Aryeh Gregor wrote:
> On Tue, Jul 20, 2010 at 2:28 PM, Platonides wrote:
>> Or a modern browser using FileReader.
>>
>> http://hacks.mozilla.org/2010/06/html5-adoption-stories-box-net-and-html5-drag-and-drop/
>
> This would be best, but unfortunately it's not yet usable for lar
On 7/20/10 9:57 AM, Michael Dale wrote:
> * The reason for the 100meg limit has to do with php and apache and how
> it stores the uploaded POST in memory so setting the limit higher would
> risk increasing chances of apaches hitting swap if multiple uploads
> happened on a given box.
I've heard ot
On 21/07/10 00:32, Daniel Kinzler wrote:
> Lars Aronsson schrieb:
>> What are the plans for increasing this limit? Would it be
>> possible to allow 500 MB or 1 GB for these file formats,
>> and maintain the lower limit for other formats?
>
> As far as I know, we are hitting the limits of http here
On 21/07/10 00:30, Roan Kattouw wrote:
> There is support for chunked uploading in MediaWiki core, but it's
> disabled for security reasons AFAIK. With chunked uploading, you're
> uploading your file in chunks of 1 MB, which means that the impact of
> failure for large uploads is vastly reduced (if
On Tue, Jul 20, 2010 at 2:28 PM, Platonides wrote:
> Or a modern browser using FileReader.
>
> http://hacks.mozilla.org/2010/06/html5-adoption-stories-box-net-and-html5-drag-and-drop/
This would be best, but unfortunately it's not yet usable for large
files -- it has to read the entire file into
I hope to begin to address this problem with the new UploadWizard, at
least the frontend issues. This isn't really part of our mandate, but I
am hoping to add in chunked uploads for bleeding-edge browsers like
Firefox 3.6+ and 4.0. Then you can upload files of whatever size you want.
I've writt
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 37-01--10 03:59 PM, Roan Kattouw wrote:
> Java applet?
I was just about to say: surely a FLOSS & decent Java applet has already
been written?!
Or maybe I have too much hope :D
- -Mike
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linu
Roan Kattouw wrote:
> 2010/7/20 Max Semenik :
>> On 20.07.2010, 19:12 Lars wrote:
>>> Requiring special client software is a problem. Is that really
>>> the only possible solution?
>>
>> There's also Flash that can do it, however it's being ignored due
>> to its proprietary nature.
>>
> Java applet
A few points:
* The reason for the 100meg limit has to do with php and apache and how
it stores the uploaded POST in memory so setting the limit higher would
risk increasing chances of apaches hitting swap if multiple uploads
happened on a given box.
* Modern html5 browsers are starting to be
Lars Aronsson schrieb:
> On 07/20/2010 04:30 PM, Roan Kattouw wrote:
>> This does need client-side support, e.g. using the Firefogg extension
>> for Firefox or a bot framework that knows about chunked uploads.
>
> Requiring special client software is a problem. Is that really
> the only possible s
2010/7/20 Max Semenik :
> On 20.07.2010, 19:12 Lars wrote:
>
>> Requiring special client software is a problem. Is that really
>> the only possible solution?
>
> There's also Flash that can do it, however it's being ignored due
> to its proprietary nature.
>
Java applet?
Roan Kattouw (Catrope)
__
Hello Lars,
I don´t think the problem is raising it to 200mb, or 150 mb but 500mb or 1
gb are a lot higher and can cause problems
Anomynous ftp access sounds like a very very very bad and evil solution...
--
Huib "Abigor" Laurens
Tech team
www.wikiweet.nl - www.llamadawiki.nl - www.forgott
On 20.07.2010, 19:12 Lars wrote:
> Requiring special client software is a problem. Is that really
> the only possible solution?
There's also Flash that can do it, however it's being ignored due
to its proprietary nature.
--
Best regards,
Max Semenik ([[User:MaxSem]])
___
On 07/20/2010 04:30 PM, Roan Kattouw wrote:
> This does need client-side support, e.g. using the Firefogg extension
> for Firefox or a bot framework that knows about chunked uploads.
Requiring special client software is a problem. Is that really
the only possible solution?
I understand that a cer
Lars Aronsson schrieb:
> What are the plans for increasing this limit? Would it be
> possible to allow 500 MB or 1 GB for these file formats,
> and maintain the lower limit for other formats?
As far as I know, we are hitting the limits of http here. Increasing the upload
limit as such isn't a solu
2010/7/20 Lars Aronsson :
> Time and again, the 100 MB limit on file uploads is a problem,
> in particular for multipage documents (scanned books) in PDF
> or Djvu, and for video files in OGV.
>
> What are the plans for increasing this limit? Would it be
> possible to allow 500 MB or 1 GB for these
Time and again, the 100 MB limit on file uploads is a problem,
in particular for multipage documents (scanned books) in PDF
or Djvu, and for video files in OGV.
What are the plans for increasing this limit? Would it be
possible to allow 500 MB or 1 GB for these file formats,
and maintain the lower
29 matches
Mail list logo
