473,703 Members | 2,355 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

Using AJAX to do inline, inpage file uploads

JMB
Hello,

I was wondering if anyone knew of any projects extending the inline upload
progress bar to utilize an inpage image uploader with bar, without having to
refresh or go to a seperate page, nor opening a second box for display of
the progress bar.

I had been using the MegaUpload that was adapted from Raditha's script at
http://www.raditha.com/upload.php . The MegaUpload script I have been using
takes the progress bar inpage, instead of opening a new page/box for the
display of the bar.

Anyhow, here is what I have been wondering. I have projects with large
amounts of 'application' usage and Web2.0 features, I guess you can say.
This includes dynamic form submissions, inline graphical interfaces,
realtime chat, realtime drawing/whiteboarding, etc. The thing I have not
been able to nail is inline progress bar usage with uploaded images/files.
Does anyone know about any projects currently working on this very thing
that I could contribute to? Or, see some demo code to have a better idea.

I am guessing my request to the server should be a put, but then I would
need what from there modifed to handle this? As PHP sux for it, and the
closest I have gotten is using a modified verision of OB_ functions. The
Perl solution seems more feasible, but I would not know where to begin using
the async nature of AJAX, I think sending the file via PUT method, and the
form variables(if any), submitted during this display of the bar from a
seperate thread to the server for storage.

I know the uploader is PHP/Perl, but with it being an AJAX-savy script,
posting here was a starting point.

Thanks in advance for direction to any/all projects, as well as suggestions,
help and comments.

Jan 2 '06 #1
12 7788

"JMB" <XX****@XXXX.XX X> wrote in message
news:i1%tf.3384 1$az4.26548@trn dny03...
Hello,

I was wondering if anyone knew of any projects extending the inline upload
progress bar to utilize an inpage image uploader with bar, without having
to refresh or go to a seperate page, nor opening a second box for display
of the progress bar.

I had been using the MegaUpload that was adapted from Raditha's script at
http://www.raditha.com/upload.php . The MegaUpload script I have been
using takes the progress bar inpage, instead of opening a new page/box for
the display of the bar.

Anyhow, here is what I have been wondering. I have projects with large
amounts of 'application' usage and Web2.0 features, I guess you can say.
This includes dynamic form submissions, inline graphical interfaces,
realtime chat, realtime drawing/whiteboarding, etc. The thing I have not
been able to nail is inline progress bar usage with uploaded images/files.
Does anyone know about any projects currently working on this very thing
that I could contribute to? Or, see some demo code to have a better idea.

I am guessing my request to the server should be a put, but then I would
need what from there modifed to handle this? As PHP sux for it, and the
closest I have gotten is using a modified verision of OB_ functions. The
Perl solution seems more feasible, but I would not know where to begin
using the async nature of AJAX, I think sending the file via PUT method,
and the form variables(if any), submitted during this display of the bar
from a seperate thread to the server for storage.

I know the uploader is PHP/Perl, but with it being an AJAX-savy script,
posting here was a starting point.

Thanks in advance for direction to any/all projects, as well as
suggestions, help and comments.


I just did something like this a few months ago and would be happy to share
the code. I have it working in both PERL and Python. The PERL is a
modified version of the MegaUpload project and the Python version is my own.
In either case I can send you the source for it. Do you also want the
javascript? That part is pretty straight forward.

Let me know via email and I will pass it along.

Jan 2 '06 #2
VK

JMB wrote:
I have projects with large
amounts of 'application' usage and Web2.0 features, I guess you can say.
This includes dynamic form submissions, inline graphical interfaces,
realtime chat, realtime drawing/whiteboarding, etc. The thing I have not
been able to nail is inline progress bar usage with uploaded images/files.
Does anyone know about any projects currently working on this very thing
that I could contribute to? Or, see some demo code to have a better idea.

I am guessing my request to the server should be a put, but then I would
need what from there modifed to handle this? As PHP sux for it, and the
closest I have gotten is using a modified verision of OB_ functions. The
Perl solution seems more feasible, but I would not know where to begin using
the async nature of AJAX, I think sending the file via PUT method, and the
form variables(if any), submitted during this display of the bar from a
seperate thread to the server for storage.

I know the uploader is PHP/Perl, but with it being an AJAX-savy script,
posting here was a starting point.


The question of upload bar is very old (since Netscape 3.0 at least).
It is one of Perpetuum Mobile's of the Web: it cannot be solved in the
given physical conditions but still many people are trying to invent it
instead of reading physics books :-)

The limitation is build into the HTTP upload model. Unlike FTP, HTTP
upload is a start/stop event w/o intermediary states: you have no idea
about uploading data until submission starts and you still have no idea
of the actual data to handle until the upload is done.
The second crutial limitation of HTTP upload is that the data is sent
in BASE64 encoding. It means that the actual submission size is *always
bigger* than the summary of file sizes to upload. The actual growth
depends heavily on the binary structure of files to upload. Roughly it
is no less than +20% and up to +100%. This is why all endless attempts
to make progress bar based on file(s) size + bandwidth speed failed so
miserably.

So in order to have a reliable progress bar for HTTP upload you have to
have *on client-side*:
1) A mechanics to know the exact upload size of files after BASE64
encoded.
2) Per packed-sent notification from HTTP upload module.

Neither of this is possible on the existing browsers. You still *can*
write your own ActiveX / plugin to take over the whole HTTP upload
functionality (or to have an FTP uploader right on the page). Nothing
you can do by just using server-side + slient-side scripting in any
shall perform combination.

P.S. Thermodynamic laws never stopped people from trying to invent a
perpetuum mobile. I'm affraid it is the case with the progress bar
neither. :-)

P.P.S. No current browser supports PUT method except W3C Amaya. Just to
save you from of one of dead branches.

Jan 2 '06 #3
VK wrote:
The second crutial limitation of HTTP upload is that the data is sent
in BASE64 encoding. It means that the actual submission size is *always
bigger* than the summary of file sizes to upload. The actual growth
depends heavily on the binary structure of files to upload. Roughly it
is no less than +20% and up to +100%. This is why all endless attempts
to make progress bar based on file(s) size + bandwidth speed failed so
miserably.

This is rubbish.

Base64 encoding always increases the size of the data by one third. It does
not depend on the 'binary structure' of the data: quite simply 3 input
bytes are encoded as 4 printable characters.
Jan 2 '06 #4
On 2 Jan 2006 03:01:27 -0800, "VK" <sc**********@y ahoo.com> wrote:
So in order to have a reliable progress bar for HTTP upload you have to
have *on client-side*:
1) A mechanics to know the exact upload size of files after BASE64
encoded.
A progress bar could reasonably be done on non-base64 encoded sizes,
the only assumption would then be that the base64 encoding is
approximately linear - that would be a sufficiently accurate approach
for what is already a very rough ready visual indicator.
2) Per packed-sent notification from HTTP upload module.


Or a callback from the server announcing "I've got N bytes", indeed
this may well be more accurate as it counts bytes recieved not sent
(some may have gone missing...)

So all that is really missing from the entire system is the total
upload size. Certainly you need a seperate communication channel from
the server to the client - a script available socket or
xmlhttprequest, or an open iframe - to send the "I've got N bytes"
messages.

It's a relatively simple job in fact to have an "uploaded 10k, 20k,30k
etc." message, indeed I implemented it one about 2001.

Jim.
Jan 2 '06 #5
VK

Duncan Booth wrote:
VK wrote:
The second crutial limitation of HTTP upload is that the data is sent
in BASE64 encoding. It means that the actual submission size is *always
bigger* than the summary of file sizes to upload. The actual growth
depends heavily on the binary structure of files to upload. Roughly it
is no less than +20% and up to +100%. This is why all endless attempts
to make progress bar based on file(s) size + bandwidth speed failed so
miserably.

This is rubbish.

Base64 encoding always increases the size of the data by one third. It does
not depend on the 'binary structure' of the data: quite simply 3 input
bytes are encoded as 4 printable characters.


My bad! I was thinking about zipping instead of base64-encoding. The
resulting file size is never less then source size + 30%
At the same time for MIME base64 it is never strictly equal to
binarySize+bina rySize/100*30. Because of additional service data is
approx 33%.
On 5-10-more files package this "approx" transforms a strict
calculation into guessing game.
Also there is such things as i) bandwidth fluctuations and ii) thread
priority management where you have no control whatsoever. The latter is
caused by the fact that a script is just another process within the
host process (browser). Periodically system will decide that it has
something more important to do and your script can wait till another
system tick (or two). On a long run it adds up significally.
The only reliable counter would be from a flag "another packet sent"
but you have none of such.

Still no one is forbidden to invent perpetuum mobiles and I expect to
see a lot of "perfectly working models" linked soon.

Jan 2 '06 #6

"JMB" <XX****@XXXX.XX X> wrote in message
news:i1%tf.3384 1$az4.26548@trn dny03...
Hello,

I was wondering if anyone knew of any projects extending the inline upload
progress bar to utilize an inpage image uploader with bar, without having
to refresh or go to a seperate page, nor opening a second box for display
of the progress bar.

I had been using the MegaUpload that was adapted from Raditha's script at
http://www.raditha.com/upload.php . The MegaUpload script I have been
using takes the progress bar inpage, instead of opening a new page/box for
the display of the bar.

Anyhow, here is what I have been wondering. I have projects with large
amounts of 'application' usage and Web2.0 features, I guess you can say.
This includes dynamic form submissions, inline graphical interfaces,
realtime chat, realtime drawing/whiteboarding, etc. The thing I have not
been able to nail is inline progress bar usage with uploaded images/files.
Does anyone know about any projects currently working on this very thing
that I could contribute to? Or, see some demo code to have a better idea.

I am guessing my request to the server should be a put, but then I would
need what from there modifed to handle this? As PHP sux for it, and the
closest I have gotten is using a modified verision of OB_ functions. The
Perl solution seems more feasible, but I would not know where to begin
using the async nature of AJAX, I think sending the file via PUT method,
and the form variables(if any), submitted during this display of the bar
from a seperate thread to the server for storage.

I know the uploader is PHP/Perl, but with it being an AJAX-savy script,
posting here was a starting point.

Thanks in advance for direction to any/all projects, as well as
suggestions, help and comments.


JMB,

The posts above are quite right about Base64 encoding and size fluctuations.
However, in my case I had clients who wanted to have some sort of progress
indicator. When someone has to upload a 50 magabyte file for instance they
want to know that the upload is still in progress after 1 minute.

My program works by using the CONTENT_LENGTH of the request as the total
size. Then, using AJAX, it retrieves the current size of the file on the
server and creates a progress bar based on the that.

Is it 100% accurate? NO!

Does it satisfy the customer by providing them with exactly what they
wanted? YES!

And does it actually work with a fair amount of accuracy? YES!

Jan 2 '06 #7
JMB
Hello, and thank you for all of the replies...

However, in the applications I am currently using, I am doing an inpage
upload progress that is about 90% accurate with time and rate of tranfer, so
this is already covered. In fact, a 100k image to a 5mb to(we had reason
to) a 1.8GB file, all displayed near-correct size, time-to-fin and percent
done in all speed cases tried. You just needed a small modifier on readout,
and an incremental for timeFromStart of the upload.

What I am having problem with, is using the XMLHttpRequest object and
asyncronous actions to allow for a file to be placed onto the server, have a
filename callback/src designation to be placed back onto that page(I know
how to do this, so, once again, this is not a problem), but all the while,
maintain the ability of the app to display a progress bar while uploading is
going on in the background(my bane with letting the progress bar do it's
thing).

I know that it can be done, but I hit a wall, and am not having any luck
going around it...seems like my programming attempts on this are trying to
push me through it!:)

Thanks again, and I look forward to any more replies that the group may be
willing to send,
JMB

"VK" <sc**********@y ahoo.com> wrote in message
news:11******** **************@ z14g2000cwz.goo glegroups.com.. .

Duncan Booth wrote:
VK wrote:
> The second crutial limitation of HTTP upload is that the data is sent
> in BASE64 encoding. It means that the actual submission size is *always
> bigger* than the summary of file sizes to upload. The actual growth
> depends heavily on the binary structure of files to upload. Roughly it
> is no less than +20% and up to +100%. This is why all endless attempts
> to make progress bar based on file(s) size + bandwidth speed failed so
> miserably.
>

This is rubbish.

Base64 encoding always increases the size of the data by one third. It
does
not depend on the 'binary structure' of the data: quite simply 3 input
bytes are encoded as 4 printable characters.


My bad! I was thinking about zipping instead of base64-encoding. The
resulting file size is never less then source size + 30%
At the same time for MIME base64 it is never strictly equal to
binarySize+bina rySize/100*30. Because of additional service data is
approx 33%.
On 5-10-more files package this "approx" transforms a strict
calculation into guessing game.
Also there is such things as i) bandwidth fluctuations and ii) thread
priority management where you have no control whatsoever. The latter is
caused by the fact that a script is just another process within the
host process (browser). Periodically system will decide that it has
something more important to do and your script can wait till another
system tick (or two). On a long run it adds up significally.
The only reliable counter would be from a flag "another packet sent"
but you have none of such.

Still no one is forbidden to invent perpetuum mobiles and I expect to
see a lot of "perfectly working models" linked soon.

Jan 2 '06 #8
VK

Sean Berry wrote:
The posts above are quite right about Base64 encoding and size fluctuations.
However, in my case I had clients who wanted to have some sort of progress
indicator. When someone has to upload a 50 magabyte file for instance they
want to know that the upload is still in progress after 1 minute.


50Mb over HTTP ?! That's at least 15.5MB of extra base64 trash on each
upload! How about environment protection (not talking about wasted
time) ? ;-)

There are plenty of FTP modules to plug in into your page for such huge
uploads.

And on relatively small uploads the "oopsy miscalculation" can easily
be up to 50% of the predicted time.

But it is indeed possible (and useful) to have an animated "currently
uploading" sign on the page. With a bit of trickery it can be done.

Jan 2 '06 #9

"VK" <sc**********@y ahoo.com> wrote in message
news:11******** **************@ g49g2000cwa.goo glegroups.com.. .

Sean Berry wrote:
The posts above are quite right about Base64 encoding and size
fluctuations.
However, in my case I had clients who wanted to have some sort of
progress
indicator. When someone has to upload a 50 magabyte file for instance
they
want to know that the upload is still in progress after 1 minute.
50Mb over HTTP ?! That's at least 15.5MB of extra base64 trash on each
upload! How about environment protection (not talking about wasted
time) ? ;-)


You are preaching to the choir with this argument.

The problem is end-users. Our clients for the most part do not deal with
(nor are they themselves) the smartest people on the planet. Heck, most of
them do not have what I would consider the basic aptitude needed for
survival... but they prove me wrong every day.
There are plenty of FTP modules to plug in into your page for such huge
uploads.

In my particular case the upload area is a bit more complex and has users
with different access and abilities. It also needed to have added
functionalites like email notifications for new uploads, description
requirements and a whole bunch of other crap. But, trying to teach my
clients to teach their clients how to successfully upload a file via FTP
wouldn't have been my first choice anyway. And on relatively small uploads the "oopsy miscalculation" can easily
be up to 50% of the predicted time.

But it is indeed possible (and useful) to have an animated "currently
uploading" sign on the page. With a bit of trickery it can be done.


As far as the progress bar, "people" like to have something really fun and
exciting like a progress bar that tells them that something is going on. At
first, I used an animation once the upload started by changing a static
image to an animated gif or something. However, I found that most "people"
didn't understand that when they are uploading a 50 megabyte file it may
take more than ten seconds and became frustrated thinking it "locked up
again". Anyway, what really matters - in my case anyway - is that the end
product does exactly what they, the brilliant people I get to deal with,
want it to do. It gives a visual indication through a recognizable and very
familiar way of how much progress has been made.

SMB
Jan 3 '06 #10

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

7
2438
by: OneSolution | last post by:
Hi All, Here's one thing that I don't know much about - file uploading. As part of my project, I will have to build a file manager of sorts - perhaps a document manager. Anyhow, this involves allowing my user to upload files to a location. I know PHP can do it - I know this because it sure does everything else ... but I don't know this from any authoritative source.
10
5016
by: 3A Web Hosting | last post by:
Hi Is it possible to perform multiple file uploads via a form? It's no problem uploading single files but I want to be able to highlight a group of files and upload them all in one go. My current method, multiple <INPUT TYPE="FILE" NAME="userfile"> entries, works but means selecting each file individually. -- Colin
1
1672
by: Doug Helm | last post by:
I should have been more clear in my subject line. I was also the poster in the "File Uploads" topic. I'm not having any luck getting file uploads to work (multi-part HTML form) on a Windows server. I'm using a very close approximation of public domain code that I found. I've tried a couple of different implementations (very similar), but I am essentially using the following test code: ...
4
4411
by: Mick | last post by:
Anyone know of any problems with this??? Using it to upload image files to a server. Most of the files work fine but occasionally one causes error with fopen() on server. Seems the 'filename/path' param is incorrect. It is actually trying to open the file using the directory path I uploaded 'from' and not 'to'. (Note: Using PHP on Novell server to open the file.) Thanks,
14
1973
by: Todd Denlinger | last post by:
Ok, I know how to upload a file in asp.net using the <input type="file" runat="server"> control. What I don't know how to do is monitor the progress of the upload so that I can show the end-user a progress bar, or something. Anyone have any ideals or can point me to a sample? Thanks,
3
20076
by: Senthil | last post by:
Hi all I'm new in ajax. How to upload a image using ajax..
4
3499
by: mcrose | last post by:
I've written theh standard applicaiton for our client to allow indexed (customer name, subject etc) file uploads via secure http using the <input type='file'http element. This works great, and has the added benefit over FTP that I can begin processing the file data stream while the download is in progress. Yeah. The client is happy, but now they want to upload multi GB files. The http request are limitted to something like 2 or 4 GB. I...
6
5101
by: Brybot | last post by:
I am trying to allow HTTP POST file uploads to my web service. Currently I have it working perfectly for a SOAP/XML request reading in a byte using MemoryStream/FileStream but I cannot figure out how to encode a file on a POST to the same web service. The definition requires a base64binary encoded file, which I have tried. The form is also using a mutlipart/form-data enctype, but I either get a 500 error or 'Request format is invalid'. ...
10
13138
by: Kal | last post by:
I recently installed Windows 2008 Server to replace a crashed hard drive on a web server with a variety of web pages including several classic ASP applications. One of these makes extensive use of file uploads using a com tool that has worked for several years. Under IIS7 doc files and jpeg files upload as before, but zip files give a 500 error. This works the same with the firewall on and off.
0
8758
marktang
by: marktang | last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However, people are often confused as to whether an ONU can Work As a Router. In this blog post, we’ll explore What is ONU, What Is Router, ONU & Router’s main usage, and What is the difference between ONU and Router. Let’s take a closer look ! Part I. Meaning of...
0
8669
by: Hystou | last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can effortlessly switch the default language on Windows 10 without reinstalling. I'll walk you through it. First, let's disable language synchronization. With a Microsoft account, language settings sync across devices. To prevent any complications,...
0
9251
Oralloy
by: Oralloy | last post by:
Hello folks, I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>". The problem is that using the GNU compilers, it seems that the internal comparison operator "<=>" tries to promote arguments from unsigned to signed. This is as boiled down as I can make it. Here is my compilation command: g++-12 -std=c++20 -Wnarrowing bit_field.cpp Here is the code in...
0
8962
tracyyun
by: tracyyun | last post by:
Dear forum friends, With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each protocol has its own unique characteristics and advantages, but as a user who is planning to build a smart home system, I am a bit confused by the choice of these technologies. I'm particularly interested in Zigbee because I've heard it does some...
1
6588
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome a new presenter, Adolph Dupré who will be discussing some powerful techniques for using class modules. He will explain when you may want to use classes instead of User Defined Types (UDT). For example, to manage the data in unbound forms. Adolph will...
0
5922
by: conductexam | last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and then checking html paragraph one by one. At the time of converting from word file to html my equations which are in the word document file was convert into image. Globals.ThisAddIn.Application.ActiveDocument.Select();...
0
4432
by: TSSRALBI | last post by:
Hello I'm a network technician in training and I need your help. I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs. The last exercise I practiced was to create a LAN-to-LAN VPN between two Pfsense firewalls, by using IPSEC protocols. I succeeded, with both firewalls in the same network. But I'm wondering if it's possible to do the same thing, with 2 Pfsense firewalls...
0
4687
by: adsilva | last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
1
3123
by: 6302768590 | last post by:
Hai team i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated we have to send another system

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.