ID:260198
 
It would be used like so:

var/file/F=input("Input a file to upload.\nThe file may not be over 500 bytes.")as null|file
if(length(F)<=500) //look into the file size that the client sent and determine it's allowed
F=client.Download(F) //actually start downloading the file
else alert("The file is over 500 bytes. Rejected!") //reject it otherwise


This would prevent unnessesary file uploads to the server by only sending the file size and such information. client.Download() would begin a download of a file. F = file identifier used in the download.
I don't think this would be fair, what if they don't want the file?
In response to Papoose
Prompt with a Yes/No.
In response to Sniper Joe
And you tell me what the difference between this and ftp() would be, other than maybe not asking where/how they want to save the file?

It just seems to me if that will be it's only purpose, it has none.
I agree with being able to check the size of a file before the upload happens, but that would require some client-side processing that BYOND doesn't have yet. Currently you'd still have to upload it to at least the host server before you can check the size, no matter how you look at it (since the size is processed on the server and not the client). Adding a Download() proc wouldn't change this at all, it would just be easier to allow length() to be checked first and then do it normally without any new procs. But you have to wait for client-side processing first.
Appearantly, the people haven't been paying attention. As my example clearly states, this would allow users to upload a file to the server rather than a file to the client.

The purpose of this is to allow players to specify files to upload (or sounds), but before actually having the server download the sound it can do safety checks like the size of the file.
I named it client.Download() because you're downloading a file from the client.
In response to Nadrew
Nadrew wrote:
But you have to wait for client-side processing first.

The client can't calculate the size? :\
In response to Android Data
Not until after the file has been downloaded.
In response to Nadrew
Um... the client is the one doing the uploading. Of course it can calculate the filesize!

It just needs to tell the server the filesize before it sends the file, that's all. Then the server can accept/reject it based on that.

It's data from the client so in theory it can't be trusted (someone could fake it if they figured out BYOND's networking protocol), but I can't think of a better solution.
In response to Crispy
Wouldn't it be possible for someone to program a sort of filesize check if he received client information about it anyway, if such a thing were put in?

Client sends the info about the size of the file, game checks and remembers it. File gets uploaded, server checks the filesize, if the numbers don't match then public humiliation for all!

Edit: 3 days old. It was still on the first page so I thought it was more recent than this. Sorry.
In response to Papoose
Papoose wrote:
And you tell me what the difference between this and ftp() would be, other than maybe not asking where/how they want to save the file?

It just seems to me if that will be it's only purpose, it has none.


Read the post please, He is talking about Uploading a file to the Server. Not downloading the file to the client
In response to Strawgate
It should probably be called client.Upload() then.
In response to Nadrew
Perhaps some kind of extra argument to input() so when it's requesting a file, it will tell you the file is too big before letting you hit okay?

Or maybe it's time a process was put in specifically for uploading files? One that allows for a custom list of uploadable extensions, file sizes, and maybe default locations. The locations should probably be limited to a small list, like desktop, Byond, documents, ect.
In response to Airjoe
Airjoe wrote:
It should probably be called client.Upload() then.

The server downloads a file from the client, hence the client.Download().
It's just a name. It could even be bound to client.Import(), having a file identifier (which is returned by any file inputs in a named list).

I propose the following:

Having something like
var/list/F=input(src,"select a file. it may not be more than 500 bytes and must be a .zip file")as null|file

Would return a list. You can then do the following:

#define EXE 0
#define ZIP 1
#define DMI 2
#define SAV 3
#define MID 4
#define MOD 5
...

if(F["size"]>500)
alert(src,"The file you specified is over 500 bytes!")
else if(F["ext"]!=ZIP)
alert(src,"The file is not a ZIP file!")
else
var/file/X=client.Import(F)
fcopy(X,"zips/[F["name"]]")


This at least illustrates three possible things you can do before actually receiving the file: you can check it's size, it's extension and it's name (alternatively you could use [X] but I included it for the purpose of showing you).

The file extension should be generated by making the client read the headers of the file, and then determine the extension using those headers. The #defines should be in stddef.dm along with possibly some others. The client then reads the headers and attempts to put one of the default values on it. If it fails, F["ext"] equals to the first 10 characters of the file, so you may create your own header checking system (perhaps for custom files that you made).

I really hope this is implemented. I believe icon games will espessially improve because of it, as they'll be able to actually check if the song sent is actually a song, as well as an icon, and check file sizes, before receiving the file, reducing a lot of lag!
In response to Android Data
Android Data wrote:
Airjoe wrote:
It should probably be called client.Upload() then.

The server downloads a file from the client, hence the client.Download().

If the server is doing the downloading, then it should be something like world.Download or client.Upload. If the client is doing the downloading, it should be client.Download or world.Upload.

Your naming system just doesn't make any sense. The client is uploading the file, so let's call it client.Download because the server is downloading it!
In response to Sarm
Sarm wrote:
Edit: 3 days old. It was still on the first page so I thought it was more recent than this. Sorry.

Don't be. If anyone complains when someone replies to a post that is only 3 days old, that person would be the one in error as far as I am concerned, not you.
In response to Airjoe
Airjoe wrote:
Your naming system just doesn't make any sense. The client is uploading the file, so let's call it client.Download because the server is downloading it!

Let's call it client.Import().
In response to Android Data
Android Data wrote:
Airjoe wrote:
Your naming system just doesn't make any sense. The client is uploading the file, so let's call it client.Download because the server is downloading it!

Let's call it client.Import().

http://www.byond.com/docs/ref/info.html#/client/proc/Import
In response to Airjoe
Airjoe wrote:
Android Data wrote:
Airjoe wrote:
Your naming system just doesn't make any sense. The client is uploading the file, so let's call it client.Download because the server is downloading it!

Let's call it client.Import().

http://www.byond.com/docs/ref/info.html#/client/proc/Import

Yesh, so make the "Query" argument also respond to file identifiers.
In response to Android Data
Android Data wrote:
Airjoe wrote:
Android Data wrote:
Airjoe wrote:
Your naming system just doesn't make any sense. The client is uploading the file, so let's call it client.Download because the server is downloading it!

Let's call it client.Import().

http://www.byond.com/docs/ref/info.html#/client/proc/Import

Yesh, so make the "Query" argument also respond to file identifiers.

No.
Page: 1 2