Ulf Dittmer wrote:What are you trying to achieve by doing this? In other words, how would a web service be better than straight HTTP file upload?
Actually I want to process this file and publish the results to our site. But then the interface should be in such a way that client should be able to push his data from the desktop application. ...so was wondering if web service could be better idea or how.
William Brogden wrote:I would certainly look into "resumable ftp" - google search found some interesting products.
Surely you want to avoid the frustration of trying to upload a GB file in the presence of interruptions.
This would be best choice when the client is desktop. But then in case of web client, we have lesser flexibility esp. when it is not RIA.
I think we agree that anything based on a single HTTP connection requiring error-less serial transmission of the whole file would be a disaster no matter what was handling the connection on the server end, right?
SO - IF we are stuck with a browser interface we have Applets and Java Web Start options to do something better.
The reality of the web is that there is a lot of bandwidth not used by a single HTTP connection. Thats why BitTorrent and JXTA exist.
You are absolutely right that over http, chances of transferring large file error-less are not very high.
I was knowing about applet option but not really java web start. Thanks Bill for pointing this out, now I can google on it.
manoj r patil wrote:Hi, I am currently analyzing on porting one file upload program to web service. The file size can be upto 1GB ...
if you really have to implement this with a webservice/http than i agree to the postings before that http is not really suitable for doing this (a GB sized transfer in one large chunk).
but maybe you could split such large files on the client and use soap-mtom-large-attachment-streaming for upload an reassemble the file on the server.
mtom-streaming is explained here: