I know ftp is an rfc and all that but these days I don't it is the most widely used upload technique. It seems like http and custom apps, like dropbox, mesh, smugmug, blazeback and so on do the uploading these days. Also I've found the ftp in practice is not any more reliable for faster than any of those other techniques.
As far as ftp being a standard in fact I'm not so sure. I've had problems with ftp server/clients being unhappy with each other. Although it probably not as big an issue for 'tog, using an ftp client from inside of a corp. network can sometimes be a big issue. Also I've found that hotel internets access often has trouble with anything other than http.
An there are lots of ftp clients to choose from, but that in itself is part of the problem. Ftp clients need to be configured and you have to know where the buttons are. They are a real hassle for help desks in that they end up have to handhold users through an app that neither has ever used before.
Some of the ftp sites I've dealt with in the past require a particular ftp client because of this and the won't support you if you don't. I remember in the past one site I had to deal with and couldn't get uploads to work. The said I *had* to switch to a particurlar ftp client and that must be the problem. I did and when we finally got things working it was their site that was messed up.
So I can see why SmugMug might not want to have an ftp site if only because of the support issues. I also don't think it would make the uploads any faster or more reliable.
I can see where you're coming from on this and have some valid points. But the request here is not to replace the current uploads with FTP, but give the option. And as far as implementation, if Exposure Manager has done it, I'm sure SM can too.
Sure, I've had problems with the SmugMug uploaders, but I've had issues at one time or another with every file transfer protocol I've ever used including Kermit, Ward Christensen's XMODEM, Chuck Forsberg's ZMODEM and everything else. Sometimes I can't even transfer a file from my computer to my wife's computer and it's just 10 ft. away.
So you've never, in the entire time you've been with SM, had any type of upload issue related to a change/upgrade/improvement in the uploaders?
It's been pretty solid for the past couple of years. The only serious problem I had was when AVG installed link scanning in its Version 9, and that messed me up for a while till the Help Desk gave me a warning about it. That issue was fixed a long time ago, but even before that it only took a couple of clicks to disable the link scanning while I was uploading and re-enable it when I was done.
Occasional failures? Sure, but like Dan, I've had those with every single file transfer scheme I've used. The only perfect protocol is the one you've never relied upon. Networking is inherently dicey. The only thing an application can do if the lower layers fail is tell you why the transfer failed. Fat lot of good that does for the typical end-user.
The addition of duplicate detection mitigated the whole issue for me, as in case of failure I don't have to worry about which files succeeded and which ones failed. I just resend the folder and let the software work out which files really need to be sent.
Occasional failures? Sure, but like Dan, I've had those with every single file transfer scheme I've used. The only perfect protocol is the one you've never relied upon. Networking is inherently dicey. The only thing an application can do if the lower layers fail is tell you why the transfer failed. Fat lot of good that does for the typical end-user.
The addition of duplicate detection mitigated the whole issue for me, as in case of failure I don't have to worry about which files succeeded and which ones failed. I just resend the folder and let the software work out which files really need to be sent.
Dunno, works for me.
I use Star Explorer which has a reliable upload queue. You put things in the queue (even across many different galleries) and it takes responsibility for getting things to Smugmug. The image doesn't come out of the upload queue until Smugmug has confirmed that it's been uploaded successfully - period. It's rather straightforward application logic that any upload app should do, but most don't. Star Explorer even persists the queue to disk so if the app crashes, the computer crashes, the power goes out, etc..., it still knows what work it has to do. When there are problems, it retries automatically because sometimes the problems are transient. Worst case, I come back hours later and the queue contains a couple images that didn't get uploaded successfully. Depending upon why they didn't go, I may just hit upload again to try them again. While Star Explorer is no user interface dream and isn't free, it does it's job quite well.
This kind of stuff is important to me when I'm launching a 14 hour upload that's supposed to run overnight and spans 30 galleries and is supposed to be done by the end of the next day. If it hiccups and stops one hour into it, I'm screwed the next day. Not only would I have to sort out what did and didn't get uploaded successfully (which can take hours), but I won't get everything done in time because the uploader stopped.
This kind of stuff is important to me when I'm launching a 14 hour upload that's supposed to run overnight and spans 30 galleries and is supposed to be done by the end of the next day. If it hiccups and stops one hour into it, I'm screwed the next day. Not only would I have to sort out what did and didn't get uploaded successfully (which can take hours), but I won't get everything done in time because the uploader stopped.
Right. My needs are more modest. The worst thing that happens in case of failure is that I get irritated. Fortunately good red wine is still fairly cheap in Spain.
If your work is time critical and massive, then it's certainly a good idea to have some higher-level retry mechanism that works while you're asleep. That still doesn't really guarantee anything will be done when you need it, but it does mean that you will have gotten the best outcome possible under the circumstances.
Nothing against Liangzan, I am sure he put lots of energy into this however.....the prob with any 3 party app is simple....If the developer decides he no longer wishes to update the app or if he is unable to keep it updated then it it becomes useless...just like NitroDesk.....If this was done by smugmug and was integrated into the system just like the other uploaders then we could pick any FTP software out there .......
But for a lot of us pros, this isn't the case. Case in point is right now, where I've been wrestling with stupid uploaders just to xfter 12gb in less than 200 files. SmugLoader stopped working after a couple of files, SM's simple uploader had hiccups on my laptop, and a java update broke it completely. Html5 is going to crash like it usually does once it runs out of memory for whatever it does with large videos that simple doesn't. I've lost 24hrs already.
I was praying that Liangzan was able to make a fix for the directories not being synced with our actually galleries after adding a gallery, etc when I tried to use smugftp right now. If this was fixed, I would've started using his app 100% by now. I want to hammer the heck out of my cable modems and utilize all 15mb available to me. Instead, I've got to play use mutliple systems and upload sessions to try to max out everything.
The biggest barrier of entry to use SM can be uploading. I wonder how many people just tried it and left when they couldn't get stuff to upload.
And what type of mechanism do you propose we use? What's out there?
He was responding to my post about my use of StarExplorer which has those capabilities. I know we've previously discussed StarExplorer for you needs, but I don't recall why you didn't use it.
FYI, using this ftp proxy you've been experimenting with is really only solving one part of the issue. You may be able to use the ftp client of your choice to get your images to the proxy, but if the proxy to Smugmug link isn't super robust, you'll still have the overall issue though you may have just lost any feedback on what did and didn't make it all the way. The last thing I'm looking for when trying to increase my reliability is adding a whole additional hop and piece of infrastructure with yet unproven code to the final destination. Plus, I don't understand how this is a good business for them to be in (providing free proxy service and free upload bandwidth) so I'd wonder why it would be a lasting solution.
And what type of mechanism do you propose we use? What's out there?
As John said, I was thinking of StarExplorer, which seems to have a loyal following. Since it has not been an issue for me, I don't know anything about other options. To maximize your chances of success, all of your equipment, including computers, external storage, modems and routers, should be on a UPS system with sufficient battery time to survive the longest transfer you expect to make. If enough money is at stake, you could also look into increasing your outbound bandwidth with optic fiber or other business class net connectivity, though you should first check with SM about whether they put any bandwidth limits on a single user upload. Dunno.
He was responding to my post about my use of StarExplorer which has those capabilities. I know we've previously discussed StarExplorer for you needs, but I don't recall why you didn't use it.
FYI, using this ftp proxy you've been experimenting with is really only solving one part of the issue. You may be able to use the ftp client of your choice to get your images to the proxy, but if the proxy to Smugmug link isn't super robust, you'll still have the overall issue though you may have just lost any feedback on what did and didn't make it all the way. The last thing I'm looking for when trying to increase my reliability is adding a whole additional hop and piece of infrastructure with yet unproven code to the final destination. Plus, I don't understand how this is a good business for them to be in (providing free proxy service and free upload bandwidth) so I'd wonder why it would be a lasting solution.
Hi, SmugFTP won't remain free. There are real costs incurred for running the service. I won't be able to pay for everyone's bandwidth. But I promise it'll be affordable. It'll be free while in beta.
I understand the concerns about reliability. I will do something about it. Probably a retry mechanism.
Yes, the app at the moment is still in beta. It is unproven. Every app has to start somewhere. So do give SmugFTP some time.
He was responding to my post about my use of StarExplorer which has those capabilities. I know we've previously discussed StarExplorer for you needs, but I don't recall why you didn't use it.
I actually bought a copy almost from the get-go. But when I was trying to send large batches, it would crash. I thought it was related to OS--all I had was 98se at the time, and I couldn't diagnose any further, so I stopped using it. Fast forward a couple of years and I tried it again for helping me upload a batch of 100GB. Same crashing problem on every OS, every computer, ever processor, everthing. So I gave up. I still have a licensed copy somewhere, but unfortunately it doesn't work for me.
FYI, using this ftp proxy you've been experimenting with is really only solving one part of the issue. You may be able to use the ftp client of your choice to get your images to the proxy, but if the proxy to Smugmug link isn't super robust, you'll still have the overall issue though you may have just lost any feedback on what did and didn't make it all the way. The last thing I'm looking for when trying to increase my reliability is adding a whole additional hop and piece of infrastructure with yet unproven code to the final destination. Plus, I don't understand how this is a good business for them to be in (providing free proxy service and free upload bandwidth) so I'd wonder why it would be a lasting solution.
Agreed that this isn't the optimal solution, but if the images get to SM reliably and I don't have to worry about it anymore, it's worth money to me.
As John said, I was thinking of StarExplorer, which seems to have a loyal following. Since it has not been an issue for me, I don't know anything about other options. To maximize your chances of success, all of your equipment, including computers, external storage, modems and routers, should be on a UPS system with sufficient battery time to survive the longest transfer you expect to make. If enough money is at stake, you could also look into increasing your outbound bandwidth with optic fiber or other business class net connectivity, though you should first check with SM about whether they put any bandwidth limits on a single user upload. Dunno.
I thought you might have had some new trick that I haven't tried. I've tried Starexplorer, Smugloader, KomodoDrop, you name it. I have UPSes, I have 75M/15M bandwidth, I've got an 8-way KVM switch and a bunch of computers. What I don't have is a reliable way to get my images to SM that's easy. Uploading is a very painful process, and I waste hours each week with finding duplicate or multiple images and stuff like that. Being able to set the upload in my FTP client and let it go would be awesome. I've used such a system on Exposure Manager. I was about to switch to EM back in the day, but SM added video, which I also needed. Video>FTP so I stayed.
Hi, SmugFTP won't remain free. There are real costs incurred for running the service. I won't be able to pay for everyone's bandwidth. But I promise it'll be affordable. It'll be free while in beta.
I understand the concerns about reliability. I will do something about it. Probably a retry mechanism.
Yes, the app at the moment is still in beta. It is unproven. Every app has to start somewhere. So do give SmugFTP some time.
I applaude your efforts and the quickness with which you address concerns. I'll be using it this year and will be giving you lots of feedback. My shooting season is almost upon me.
More variety in SM automated workflow
I have read this thread with great interest, especially as I've been dying for FTP since I joined SM 2 years ago!
But I think the discussion should not be about whether FTP is right or wrong; it should be about SM offering more variety in automated workflow solutions!
Because none of the tools that I've found on the net or via the wiki can offer the level of automation I require. So I ended up using "Send to Smugmug" because it's by far the easiest and most reliable to use.
The reason for my automated workflow desire: I load photos to my laptop, do the selections, this is then all sync'd to my NAS device, which in turn makes automated daily backups to my LiveDrive account... via FTP...... other than my photos and videos because I have these at SM of course! Now, I could upload photos and videos twice (to LD and SM) but even with a fairly reasonable 4mbps upload, try uploading gigabytes of photos and videos - twice. It's not fun, not to mention hogs my bandwidth big time.
So my hope is to have everything fully integrated one day, and the solution for this would be something along the lines of FTP, Secure FTP, rsync, SMB, NFS, etc. I've been using FTP for 20+ years and to date it's still one of the main protocols to move files around. Security can be good if set up well (e.g. authorisation by IP only).
But honestly guys, just because you don't hear widespread complaints about the standard SM uploading solutions doesn't mean that there is no need for improvement with the standard SM uploading mechanisms!
I have always seen SM synonymous to innovation - I hope you will continue to do so. Offering another, proven automated workflow solution, such as FTP, is something I really hope you take into consideration. Outside of dgrin and uservoice, I am sure that many others would really benefit from this.
I've been using FTP for 20+ years and to date it's still one of the main protocols to move files around. Security can be good if set up well (e.g. authorisation by IP only).
But honestly guys, just because you don't hear widespread complaints about the standard SM uploading solutions doesn't mean that there is no need for improvement with the standard SM uploading mechanisms!
And this a good point that I completely agree with.
I can't do anything about my country though. Its not fair that being a non-US citizen means I'm likely to be dishonest.
My motivation for doing the app is the frustration with the upload options. I want something fast and reliable. And I do not want to navigate to the page everytime I upload.
Thank you for addressing our concerns. If only you could see what your fellow countrymen/women do to dishonor your reputation here, you'd be leery too.
Wow, gotta love Americans. As if we've never done anything dishonorable. :-P
Also, this dude is from Singapore. Perhaps you're confusing him with (or lumping him in with all of) those damn Chinese?
I want to start a fund to send Nikolai to Samir's house to troubleshoot his Star*Explorer issues. :-}
I'd love for SE to work for me. I've lost 4hrs today due to uploading issues...and I think simple uploader crashed...AGAIN...grr. It shouldn't be this hard to upload 14gb.
Wow, gotta love Americans. As if we've never done anything dishonorable. :-P
Also, this dude is from Singapore. Perhaps you're confusing him with (or lumping him in with all of) those damn Chinese?
(I'm Chinese-American, myself, as it happens.)
Not saying we're perfect either, but 'Made in China' has political views associated with it now. And recalls from Chinese manufacturers, etc haven't helped. And from what I recall, he's from China or is at least Chinese. Very nice guy as we talk quite often trying to make smugftp perfect.
We have disabled all uploads to SmugMug using SmugFTP. The decision was made based on extremely poor performance, with about 95% failure rate on uploads that also caused a lot of retries and as such a lot of unnecessary load. We understand that many of you would like to have FTP uploading option to SmugMug, but the observed failure rate vastly negates the benefits this particular tool provides to the user community as a whole. We suggest that you use one of our built in uploaders or any other tools we and our vibrant developer community have cooked up for all of us to enjoy. Should the tool be improved and demonstrated to be working on acceptable level we can re-visit this decision.
Feel free to contact me directly for more information if needed.
Liangzan works tirelessly on trying to make this work. This is a BETA product and hence these type of issues are to be expected. I think it is wholly unfair for you to disable a product that has the potential to fill a badly needed request for FTP uploading. If SM isn't going to do it, shutting off someone else's product that can is just going to make more people angry.
I have not observed the same failure rates and most of my images get to exactly where I want them. And another user has successfully uploaded 75Gb using smugftp according to the discussion on the feedback system.
If the built-in uploaders worked for us, we would use them. But obviously, they don't. Your suggestion is noted, but it shows you're not paying attention to the real issue here.
I think what Mikka is trying to say is that it's affecting the server. I don't know for sure but that's what I took away from it and if that's the case, it could be affecting other users which is reason enough to disable it.
Moderator Journeys/Sports/Big Picture :: Need some help with dgrin?
I'm not sure that the users of SmugFTP would see the failures. I would assume that the server hosting SmugFTP would be doing retries on failures so the end user would have seen a successful upload even though there may have been many failures on the SmugMug end of things.
I think what Mikka is trying to say is that it's affecting the server. I don't know for sure but that's what I took away from it and if that's the case, it could be affecting other users which is reason enough to disable it.
Indeed that is the correct interpretation. The way the SmugFTP tried to upload images was affecting the service other users. I'm more than happy to work with Liangzan to rectify the issues with the product and after that re-visit our decision to block it.
Indeed that is the correct interpretation. The way the SmugFTP tried to upload images was affecting the service other users. I'm more than happy to work with Liangzan to rectify the issues with the product and after that re-visit our decision to block it.
I understand, but if there's that many people trying to use the service, then why not get in touch with him rather than announcing that you've disabled the application.
I understand, but if there's that many people trying to use the service, then why not get in touch with him rather than announcing that you've disabled the application.
Problems that affect usability like this can be caused by one user. If it's service impacting; I think it's fair to disable the service. Especially if it's not an officially supported protocol.
The good news is that an avenue for resolving what ever the issue is is available to the author if he chooses to avail himself of it.
Moderator Journeys/Sports/Big Picture :: Need some help with dgrin?
Problems that affect usability like this can be caused by one user. If it's service impacting; I think it's fair to disable the service. Especially if it's not an officially supported protocol.
The good news is that an avenue for resolving what ever the issue is is available to the author if he chooses to avail himself of it.
I completely understand the part about the service. My point is that if Nikolai had an issue with SE causing a similar issue, you'd try to get in touch with him before shutting off SE out of the blue. I don't get why SM didn't extend the same courtesy to Liangzan and smugftp.
I completely understand the part about the service. My point is that if Nikolai had an issue with SE causing a similar issue, you'd try to get in touch with him before shutting off SE out of the blue. I don't get why SM didn't extend the same courtesy to Liangzan and smugftp.
Neither one of us know the details so I don't think it's fair to make comparisons like this or to speculate why that decision was made other than it was service impacting.
Moderator Journeys/Sports/Big Picture :: Need some help with dgrin?
Neither one of us know the details so I don't think it's fair to make comparisons like this or to speculate why that decision was made other than it was service impacting.
What's not fair is SM's treatment of smugftp. I emailed Liangzan, and he told me what happened. I know this same treatment would not have been applied to Nikolai or SE. I don't know what SM's reasoning is beyond the service issue, but SM's attitude towards smugftp definitely indicates there is one.
What's not fair is SM's treatment of smugftp. I emailed Liangzan, and he told me what happened. I know this same treatment would not have been applied to Nikolai or SE. I don't know what SM's reasoning is beyond the service issue, but SM's attitude towards smugftp definitely indicates there is one.
You do not know what may or may not happen with SE because it hasn't happened and your assumptions are unfair to both Nikolai and SmugMug.
Moderator Journeys/Sports/Big Picture :: Need some help with dgrin?
Comments
Want faster uploading? Vote for FTP!
http://www.danalphotos.com
http://www.pluralsight.com
http://twitter.com/d114
Occasional failures? Sure, but like Dan, I've had those with every single file transfer scheme I've used. The only perfect protocol is the one you've never relied upon. Networking is inherently dicey. The only thing an application can do if the lower layers fail is tell you why the transfer failed. Fat lot of good that does for the typical end-user.
The addition of duplicate detection mitigated the whole issue for me, as in case of failure I don't have to worry about which files succeeded and which ones failed. I just resend the folder and let the software work out which files really need to be sent.
Dunno, works for me.
This kind of stuff is important to me when I'm launching a 14 hour upload that's supposed to run overnight and spans 30 galleries and is supposed to be done by the end of the next day. If it hiccups and stops one hour into it, I'm screwed the next day. Not only would I have to sort out what did and didn't get uploaded successfully (which can take hours), but I won't get everything done in time because the uploader stopped.
Homepage • Popular
JFriend's javascript customizations • Secrets for getting fast answers on Dgrin
Always include a link to your site when posting a question
Right. My needs are more modest. The worst thing that happens in case of failure is that I get irritated. Fortunately good red wine is still fairly cheap in Spain.
If your work is time critical and massive, then it's certainly a good idea to have some higher-level retry mechanism that works while you're asleep. That still doesn't really guarantee anything will be done when you need it, but it does mean that you will have gotten the best outcome possible under the circumstances.
I was praying that Liangzan was able to make a fix for the directories not being synced with our actually galleries after adding a gallery, etc when I tried to use smugftp right now. If this was fixed, I would've started using his app 100% by now. I want to hammer the heck out of my cable modems and utilize all 15mb available to me. Instead, I've got to play use mutliple systems and upload sessions to try to max out everything.
The biggest barrier of entry to use SM can be uploading. I wonder how many people just tried it and left when they couldn't get stuff to upload.
Want faster uploading? Vote for FTP!
FYI, using this ftp proxy you've been experimenting with is really only solving one part of the issue. You may be able to use the ftp client of your choice to get your images to the proxy, but if the proxy to Smugmug link isn't super robust, you'll still have the overall issue though you may have just lost any feedback on what did and didn't make it all the way. The last thing I'm looking for when trying to increase my reliability is adding a whole additional hop and piece of infrastructure with yet unproven code to the final destination. Plus, I don't understand how this is a good business for them to be in (providing free proxy service and free upload bandwidth) so I'd wonder why it would be a lasting solution.
Homepage • Popular
JFriend's javascript customizations • Secrets for getting fast answers on Dgrin
Always include a link to your site when posting a question
Hi, SmugFTP won't remain free. There are real costs incurred for running the service. I won't be able to pay for everyone's bandwidth. But I promise it'll be affordable. It'll be free while in beta.
I understand the concerns about reliability. I will do something about it. Probably a retry mechanism.
Yes, the app at the moment is still in beta. It is unproven. Every app has to start somewhere. So do give SmugFTP some time.
Agreed that this isn't the optimal solution, but if the images get to SM reliably and I don't have to worry about it anymore, it's worth money to me. I thought you might have had some new trick that I haven't tried. I've tried Starexplorer, Smugloader, KomodoDrop, you name it. I have UPSes, I have 75M/15M bandwidth, I've got an 8-way KVM switch and a bunch of computers. What I don't have is a reliable way to get my images to SM that's easy. Uploading is a very painful process, and I waste hours each week with finding duplicate or multiple images and stuff like that. Being able to set the upload in my FTP client and let it go would be awesome. I've used such a system on Exposure Manager. I was about to switch to EM back in the day, but SM added video, which I also needed. Video>FTP so I stayed.
Want faster uploading? Vote for FTP!
Want faster uploading? Vote for FTP!
Markham
www.twitter.com/markhambennett
Want faster uploading? Vote for FTP!
I have read this thread with great interest, especially as I've been dying for FTP since I joined SM 2 years ago!
But I think the discussion should not be about whether FTP is right or wrong; it should be about SM offering more variety in automated workflow solutions!
Because none of the tools that I've found on the net or via the wiki can offer the level of automation I require. So I ended up using "Send to Smugmug" because it's by far the easiest and most reliable to use.
The reason for my automated workflow desire: I load photos to my laptop, do the selections, this is then all sync'd to my NAS device, which in turn makes automated daily backups to my LiveDrive account... via FTP...... other than my photos and videos because I have these at SM of course! Now, I could upload photos and videos twice (to LD and SM) but even with a fairly reasonable 4mbps upload, try uploading gigabytes of photos and videos - twice. It's not fun, not to mention hogs my bandwidth big time.
So my hope is to have everything fully integrated one day, and the solution for this would be something along the lines of FTP, Secure FTP, rsync, SMB, NFS, etc. I've been using FTP for 20+ years and to date it's still one of the main protocols to move files around. Security can be good if set up well (e.g. authorisation by IP only).
But honestly guys, just because you don't hear widespread complaints about the standard SM uploading solutions doesn't mean that there is no need for improvement with the standard SM uploading mechanisms!
I have always seen SM synonymous to innovation - I hope you will continue to do so. Offering another, proven automated workflow solution, such as FTP, is something I really hope you take into consideration. Outside of dgrin and uservoice, I am sure that many others would really benefit from this.
Thanks for reading
cmmc
Glad to have you for the cause.
Want faster uploading? Vote for FTP!
Wow, gotta love Americans. As if we've never done anything dishonorable. :-P
Also, this dude is from Singapore. Perhaps you're confusing him with (or lumping him in with all of) those damn Chinese?
(I'm Chinese-American, myself, as it happens.)
Not saying we're perfect either, but 'Made in China' has political views associated with it now. And recalls from Chinese manufacturers, etc haven't helped. And from what I recall, he's from China or is at least Chinese. Very nice guy as we talk quite often trying to make smugftp perfect.
Want faster uploading? Vote for FTP!
Feel free to contact me directly for more information if needed.
http://msphoto.smugmug.com
http://twitter.com/tasmanic
I have not observed the same failure rates and most of my images get to exactly where I want them. And another user has successfully uploaded 75Gb using smugftp according to the discussion on the feedback system.
If the built-in uploaders worked for us, we would use them. But obviously, they don't. Your suggestion is noted, but it shows you're not paying attention to the real issue here.
Want faster uploading? Vote for FTP!
I'm not sure that the users of SmugFTP would see the failures. I would assume that the server hosting SmugFTP would be doing retries on failures so the end user would have seen a successful upload even though there may have been many failures on the SmugMug end of things.
http://www.danalphotos.com
http://www.pluralsight.com
http://twitter.com/d114
http://msphoto.smugmug.com
http://twitter.com/tasmanic
Want faster uploading? Vote for FTP!
Problems that affect usability like this can be caused by one user. If it's service impacting; I think it's fair to disable the service. Especially if it's not an officially supported protocol.
The good news is that an avenue for resolving what ever the issue is is available to the author if he chooses to avail himself of it.
Want faster uploading? Vote for FTP!
Neither one of us know the details so I don't think it's fair to make comparisons like this or to speculate why that decision was made other than it was service impacting.
Want faster uploading? Vote for FTP!
You do not know what may or may not happen with SE because it hasn't happened and your assumptions are unfair to both Nikolai and SmugMug.