Demaestro
msg:3939046 | 9:02 pm on Jun 23, 2009 (gmt 0) |
Can I ask why they aren't able to download it? The server crashes? The browser time out?
|
dcaspian
msg:3939095 | 10:14 pm on Jun 23, 2009 (gmt 0) |
Thanks for the response! I unfortunately can't provide an answer that specific without being charged for the time it would take to get one from the CMS's developer. My understanding of what's happening is that the webstore is part of a proprietary CMS (which we're stuck with) that's database-driven and can't provide people with a file of that size from the data field it resides in... This is the rough response from the CMS's author, who was also the one who suggested a smaller downloadable file that would then download the file (a ~56MB iPOD download) people were paying for. Thanks again for the response,
Daniel
|
willybfriendly
msg:3939106 | 10:22 pm on Jun 23, 2009 (gmt 0) |
How about ftp.domain.tld/path/to/file
|
dcaspian
msg:3939650 | 6:03 pm on Jun 24, 2009 (gmt 0) |
Hi willybfriendly, Thanks for the response but I'm not sure what you mean here... should I be cloaking that ftp info in an executable file? Basically because of the limits of the store the client uses, I am only able to provide the solution that consists of a file that then downloads the larger file when executed. I would like to cloak the URL info so that people can't share it too freely but I guess that part isn't too big a deal. Come to think of it I might just serve the file as a shortcut... this wouldn't exactly be free of file-sharing but I could monitor the number of downloads vs the number of paid transactions :) Thanks for your help guys!
Daniel
|
willybfriendly
msg:3940310 | 3:44 pm on Jun 25, 2009 (gmt 0) |
| Come to think of it I might just serve the file as a shortcut... this wouldn't exactly be free of file-sharing but I could monitor the number of downloads vs the number of paid transactions |
|
This is exactly what I was implying. Per your earlier post, the files are being stored in your DB (presumably a BLOB?) and served from there. Strikes me as inefficient at best. Store a link to the file in the DB and the file on the server. You can password protect the folder the file is in. Then, provide those purchasing the file the link and password. That would cut down on sharing - at least off your server.
|
Demaestro
msg:3940319 | 3:51 pm on Jun 25, 2009 (gmt 0) |
| Then, provide those purchasing the file the link and password. That would cut down on sharing - at least off your server. |
|
If you want to get anal about it. You can generate passwords and expire them after being used. If the purchaser has a failed download they can request a new pw. That way people can't share links.
|
willybfriendly
msg:3940329 | 3:59 pm on Jun 25, 2009 (gmt 0) |
| That way people can't share links... |
|
And we all know people don't share files ;)
|
dcaspian
msg:3940384 | 5:36 pm on Jun 25, 2009 (gmt 0) |
Guess I should just serve up a link to the file. I guess it really doesn't matter if the file's available as a free-for-all, whether people share links or share files either way if they want to distribute they will. I'll monitor downloads vs transactions and if the numbers are too divergent do the single-use password solution as mentioned above. Thanks again for all the help
D
|
|
