multiupload

[Rafi]

why should hfs unzip in place of me?

I agree with you, rejetto, but I think I understand the logic of the suggestion.

The answer - is "me"=the client user (uploader). Say he wants to send you a file x.txt of  100MB. The most efficiant way is to zip it (to 5M...) send it, and unzip it. He can do the zip, but cannot do the unzip, and do not want the server user to bother.

For example - this is a good procedure if you (the client) are hosting a site on the HFS server side. You take the whole site, zip the tree and send it over + unzip,  and walla - you get a remote site...

Well, as I said- V 2.2 is good enough for that ...

[Mr. Anon]

How are you going to send folders which contains for example 40 files in it? Because browsers (at least IE) could only browse and not upload folders, it will take really long for a user to select 40 files in different upload browse fields. At least I couldn't figure out a way to select a folder and upload it.

And to make this simpler and faster, unzipping a zip file will be convenient enough for users to upload 40 files at once. Because a zip file is only one file. And after HFS decompresses the file, the 40 files appears on HFS just as it were uploaded by different upload fields.

Do you get my point?

For example - this is a good procedure if you (the client) are hosting a site on the HFS server side. You take the whole site, zip the tree and send it over + unzip, and walla - you get a remote site...

EXACTLY! Same for other files as well... not just websites.

[Rafi]

2  for the price of 1 ...

[Mr. Anon]

Thank you Rafi for expressing my point...
Maybe it's just my poor English  :?

[Mr. Anon]

I'm not sure, but I think  that FTP may be incorporating internally a compression algorithm, per RFC 468.

I have never heard of such thing. Hmm...  :?

V 2.0 - support for single file upload. this will test the basic engine, and the security. Also - resuming uploads mechanism.

V 2.1 - add support for multiple files. This will test the final GUI, multiple file download, directory/tree or any combinations, and progress report/graph (client and server sides)

1. Would the resume mechanism be based on FTP?
2. I don't think multiple files upload will need stages because for multiple files to be uploaded, HFS will only have to store both POST data section into files.
3. What's multiple file download, directory/tree or any combinations?
4. Is progress report possible under HTTP without Java?

[Rafi]

1. Would the resume mechanism be based on FTP?

the Q is for rejetto...

3. What's multiple file download, directory/tree or any combinations?

it's my mistake, I meant upload. but when you thing of it , just reverse sides, and it's for downloads too...

4. Is progress report possible under HTTP without Java?

And what if java IS needed?
Yes, look here for a live demo (#3)
http://www.aspupload.com/livedemo.html

by the way - lot's of nice stuff here : http://www.aspupload.com


BTW - maybe you have to think again , rejetto , on the FTP approach. It might reduce the attraction of the downloader since that if you use FTP, you might just want to use it for download as well. I know I said before "why invent the wheel" ...   :?

[Mr. Anon]

For what I have known now, the HTTP protocol does not support resuming of files that are being uploaded. (However, it should be possible via a Java applet) Would be so grateful if someone were to be nice enough to write an open source Java applet for rejetto so that HFS uploading will support resuming.

In addition, I don't think progress reports are possible via HTTP because HFS cannot send a reply back before the POST command is completed. (Plus, HFS doesn't know the size of the file until the file has been uploaded or does the browser specify the size in the Boundary header?)

I agree with Rafi on the FTP part. Because HFS is designed as a HTTP server, adding a FTP server into it just makes users just the FTP part of the program instead. So what's the point of making a HTTP server if users are not using it? Maybe FTP File Server?  
The unzip upload capability will currently solve the issue of "multiple files" being uploaded.

[Rafi]

Just two more comments -
1. upload will eventually need to be accompanied with a remote files manager, so the current HFS web-page design should  be modified for it(see my screenshot above) .
2. I think we are going the worng way about the spec here. rejetto can post a short spec. of the main features he is proposing/going  to put in ver 2. Others (like us...) can comment on that. That is if you like to ... rejetto...  you can also surprise us all with  a prototype...  

[Mr. Anon]

Just two more comments -
1. upload will eventually need to be accompanied with a remote files manager, so the current HFS web-page design should  be modified for it(see my screenshot above) .
2. I think we are going the worng way about the spec here. rejjeto can post a short spec. of the main features he is proposing/going  to put in ver 2. Others (like us...) can comment on that. That is if you like to ... rejjeto...  you can also surprise us all with  a prototype...  

1. Yes, I agree. But who is going to make that File Manager? And in what assembly language? rejetto have stated that he will need an open source Java applet in order for resuming of uploads to work. Although I am not sure on others features. (Such as progress reports etc.)
2. Good Idea!
3. Typo in "rejjeto", should be "rejetto".  :lol:

[Rafi]

3. Typo in "rejjeto", should be "rejetto".  :lol:

Thanks, sorry about that  :#)
it will be fixed in V2 RC127 ...

[rejetto]

1. HTTP may support file resuming on upload, via headers, but actually no client support it. useless.
2. Yes, i can't let client-side user know about progress on upload.
3. want to use HFS for web hosting? you fools
   anyway, i think the unzip feature should be done by an external app, not by HFS, as already said, so you can use RAR as well.
4. the activex solution is to be used only on IE. and i don't use IE . a java applet would be much better.
5. having access to files with multiple protocols is useful, IMO. the fact a user always uses FTP does not involve what other users do.

[Mr. Anon]

1. Yes, HTTP could resume if the client sends the Content-Range header in the POST command, but no browser does that because no browser knows the uploaded size of the file.
3. Ahem... In the other thread you said HFS will be meant to by a webserver. So what if a user wants to upload a folder where it has images and webpages and describes the content in HFS?
4. I agree. Since Java is cross-flatform.
5. Since you choose to implement a FTP server in HFS, what commands would it support? Would it be customizable / "disable"able? Would HFS users be able to choose the PASV range?

[TGeRi]

Another suggestion for unzip feature.

I think rejetto-s idea that there will be 3rd party programs
to do these things is good.

My suggestzion is that u don't have to chooose "extract me"
on upload but after uplading a file there would be a way to
unzip zipped files on the server (if u are the user who uploaded it)
A button or something.

I hope u understand me.

Sorry for my baad english.

TGeRi

[Mr. Anon]

(if u are the user who uploaded it)

Then should a new permission system be made?
IMO, it requires more work than just the classic "extract me" method.

[rejetto]

hmm, i was thinking about a "call script on upload".
to fulfil tgeri's idea we need a "call script on request" (request = link).
hmmm....