Anything that uploads is going to need access to your account. Uploads are restricted to the site owner so that has to be authenticated.
Sure. Obviously you have to trust some entities to do anything useful. To even use online banking you're trusting a lot more pieces than an average person realizes (your OS, ISP, browser, DNS infrastructure, Certificate Authorities, etc., etc.). The idea is to minimize the number of pieces involved, compartmentalize, and maximize security of each piece. The fact that I have to trust SM with its own login doesn't mean that I will trust its login to any other piece of closed source software, or that I will trust SM with say login to my online banking.
Filezilla (or any other FTP client) and StarExplorer are on the opposite ends of security risk scale, in my opinion. One is an open source software with many applications and huge user base, many of whom are technical. If there was a backdoor in it, I would expect it to be discovered rather quickly, and it would make the news. Compared to SE with a small user base most of whom are not technical (in a software/security area; I'm sure many are very technical in photography).
I'm sure it would be way, way eaiser for Smugmug to fix resumable video uploads using their current protocols than to implement ftp from scratch.
This is where you go wrong. They would not need to implement ftp from scratch. Other people already did it, and made the result free and open-source, so that others can benefit. Between free open-source software and SM implementation of uploads via email, SM probably already has all the pieces necessary to make FTP uploads work. They'd need to spend effort on integrating them, testing, UI modifications, etc., but in my opinion it is not much more difficult than making their existing stuff work reliably with all the features, and the result would be much more robust, and require less ongoing maintenance.
Sure, I understand you have a fondness for ftp, but there are other solutions and they work fine. I, for one, would rather Smugmug put their resources into other issues that will benefit far more users.
My fondness of ftp comes only from the fact that the problem at hand is transferring files reliably, and ftp, being the File Transfer Protocol, is the best solution I know. If we were talking about browsing web content, you'd discover my fondness of http, especially if SM was pushing their own custom implementation in lieu of.
This is where you go wrong. They would not need to implement ftp from scratch. Other people already did it, and made the result free and open-source, so that others can benefit. Between free open-source software and SM implementation of uploads via email, SM probably already has all the pieces necessary to make FTP uploads work. They'd need to spend effort on integrating them, testing, UI modifications, etc., but in my opinion it is not much more difficult than making their existing stuff work reliably with all the features, and the result would be much more robust, and require less ongoing maintenance.
I presume you're guessing here on Smugmug's infrastructure and how easy or hard it would be to implement authenticated and secure ftp. If you read what Google encountered, they decided it was not easy at all to make it work securely at scale. In fact, it was such a pain that they abandoned it, even after they had invested a lot in making it work for their users for several years. And, even when it was working, they had horrible failiure rates (10%). I don't know the details of their implementation, but they certainly didn't find it as easy as you are representing. And, they likely had even smaller files to deal with than Smugmug and probably lower volume per user.
I'll stand by my opinion that I'd rather Smugmug invest in other things than invest in this. That's my opinion and you're welcome to have a different opinion, but I think you're oversimplifying how easy it would be to implement this.
If you read what Google encountered, they decided it was not easy at all to make it work securely at scale.
I have no idea what Google was trying to do with it. I'm not saying that ftp is a solution to everything, only to reliable file transfer. Blog publishing is different than bulk file transfer.
And, they likely had even smaller files to deal with than Smugmug and probably lower volume per user.
You got this backward. It's precisely because they deal with fewer and smaller files that ftp is adding less value for them, and they can live with http or whatever other means they're using.
I'll stand by my opinion that I'd rather Smugmug invest in other things than invest in this. That's my opinion and you're welcome to have a different opinion, but I think you're oversimplifying how easy it would be to implement this.
Look, we both don't want SM wasting resources on unnecessary stuff. To me, reimplementing something that's already been implemented, and reinventing the wheel is the waste. And by the way they're not only wasting their own resources, but also other developers' (although also providing an income stream for some), and the customers'.
As far as oversimplification, I don't think so. Running ftp server is not rocket science. Creating ftp account when a button is clicked in control panel is easily doable, my hosting provider does it from their control panel. Importing files after they've been transfered could be done the same way the mail server does it. What other major components are missing?
Look, we both don't want SM wasting resources on unnecessary stuff. To me, reimplementing something that's already been implemented, and reinventing the wheel is the waste. And by the way they're not only wasting their own resources, but also other developers' (although also providing an income stream for some), and the customers'.
As far as oversimplification, I don't think so. Running ftp server is not rocket science. Creating ftp account when a button is clicked in control panel is easily doable, my hosting provider does it from their control panel. Importing files after they've been transfered could be done the same way the mail server does it. What other major components are missing?
Look, ftp is NOT consumer friendly - the majority of consumers don't even know what it is or what to do with it. It's for more advanced users. As such, Smugmug is always going to have other, more consumer friendly, uploading options. Adding ftp is not going to replace anything - just be another uploading technology to support and more work to implement and run. So, I don't buy the argument that it's saving Smugmug any dev time.
I honestly don't know how it would compare in a head-to-head vs. what they have now in a technology shoot-out, but that isn't really the point. They have what they have and they're always going to have an HTTP-based offering for non-ftp savvy folks. So, to me it's really just a matter of whether it's worth adding yet another uploading technology.
Anyway, I think we've exhausted the point of the discussion without knowing a lot more about Smugmug's insides so I'll bow out now.
Did you read the referenced article because I don't think you responded to the main points in that article? I, for one, put some faith into Google's understanding of large scale data movement and their experience with blogger. Google doesn't give up because something's hard. They give up when there are better ways to solve the problem. They rewrote their ftp infrastructure a couple times and still ended up with 10% failures. That's horrible. Then, due to data structure changes, they were left with more rewrites.
I read the article, but didn't really see how the shortcomings applied to SM's upload model. Google's Blogger infrastructure seems vastly different than SM's. There have been things that I thought would be next to impossible to implement on SM that are running today. I think SM has the talent to do almost anything with their product.
As I've said before, in my 5+ years experience with Smugmug, the best way I've found to reliably move a lot of photos into Smugmug is with StarExplorer. Not only does it have a reliable disk-based queue and keeps track of what was successfully uploaded or not so you know what got there and what didn't, but you can also upload to lots of different galleries in one unattended upload so you don't have to dump zillions of images into one gallery. I never understood why it didn't work for you, but it's been my best way to solve the problem.
Your guess is as good as mine. I've worked with the author on finding out if there's anything out of the ordinary in my account or the almost dozen computers I've tried it on. Mass upload of all my photos shot prior to SM is why I bought it in the first place, and even used it early on for new galleries. But as the number of galleries numbered into the thousands and images into the hundreds of thousands, it just konks out. I even tried it recently and it crashed after a few hours--no queue saved, no way to properly resume using SE.
But you also bring up an important point--is a third party solution the ultimate solution? Or does it simply introduce another point of failure in the workflow? How many times has an API change or a SM update broken the third party uploaders? Uploaders that for the most part are made by regular people that volunteered their time to create something, and that may not have time to support it? It's hard to build a solid workflow on a uploader that may fail intermittantly.
If you're really just trying to do online backup of a lot of images, then I'd suggest BackBlaze. It has a background uploader that just works in the background forever. I've put more than 500GB online through BackBlaze. It's less than $50 year for unlimited online backup and a totally automated system.
I've looked into all these solutions, and they don't work for me. Either they lock away data with too many proprietary means of access and retrival, or their uploaders have quirks and overhead that makes them unattractive, besides simply being slow. Uploading all my images to SM accomplishes more than just backup. Thanks to the new smart galleries feature, I'm able to go through and process images from years back as long as they're uploaded just once.
The hard part as been the upload of photos from the previous years. The only way to simultaneous saturate all three of my cable modems (and thereby have the fastest effective upload speed) is to have multiple streams uploading simultaneously. Komodo Drop is the only uploader I've tried that could do this, but it would also crash before all the galleries would complete. The only reliable way to upload with multiple streams has been to use multiple sessions of simple uploader (as many as 20 at a time on multiple computers on the network) until the simple uploader finally crashes from being reused over and over for hours. Then, the systems must be rebooted and the process continues.
I think the simple uploader would actually work for a large upload if it would be able to handle multiple upload streams simultaneously and have an ability to queue. Functionally, that's all FTP really adds besides universal compatibility.
I've been using SmugBrowser for uploads, and while it is better than it used to be, using it for videos is a big PITA (with it starting 6 simultaneous uploads of large videos, killing bandwidth for anything else, and needing to restart everything from beginning after any hick-up).
Hmm...I'll have to re-visit SmugBrowser too. It also had crashing issues when I last tried it. But the simultaneous uploads and saturation of bandwidth is exactly what I'm looking for.
I read the article, but didn't really see how the shortcomings applied to SM's upload model. Google's Blogger infrastructure seems vastly different than SM's. There have been things that I thought would be next to impossible to implement on SM that are running today. I think SM has the talent to do almost anything with their product.
Your guess is as good as mine. I've worked with the author on finding out if there's anything out of the ordinary in my account or the almost dozen computers I've tried it on. Mass upload of all my photos shot prior to SM is why I bought it in the first place, and even used it early on for new galleries. But as the number of galleries numbered into the thousands and images into the hundreds of thousands, it just konks out. I even tried it recently and it crashed after a few hours--no queue saved, no way to properly resume using SE.
But you also bring up an important point--is a third party solution the ultimate solution? Or does it simply introduce another point of failure in the workflow? How many times has an API change or a SM update broken the third party uploaders? Uploaders that for the most part are made by regular people that volunteered their time to create something, and that may not have time to support it? It's hard to build a solid workflow on a uploader that may fail intermittantly.
I've looked into all these solutions, and they don't work for me. Either they lock away data with too many proprietary means of access and retrival, or their uploaders have quirks and overhead that makes them unattractive, besides simply being slow. Uploading all my images to SM accomplishes more than just backup. Thanks to the new smart galleries feature, I'm able to go through and process images from years back as long as they're uploaded just once.
The hard part as been the upload of photos from the previous years. The only way to simultaneous saturate all three of my cable modems (and thereby have the fastest effective upload speed) is to have multiple streams uploading simultaneously. Komodo Drop is the only uploader I've tried that could do this, but it would also crash before all the galleries would complete. The only reliable way to upload with multiple streams has been to use multiple sessions of simple uploader (as many as 20 at a time on multiple computers on the network) until the simple uploader finally crashes from being reused over and over for hours. Then, the systems must be rebooted and the process continues.
I think the simple uploader would actually work for a large upload if it would be able to handle multiple upload streams simultaneously and have an ability to queue. Functionally, that's all FTP really adds besides universal compatibility.
Ahhh, trying to saturate three cable modems at once - that is a bit of a different requirement than most encounter. When I used to do large uploads on a very, very fast internet connection and not even SE would come close to using the available capacity, I would use 10 simultaneous copies of the older java uploader going at once on the same computer. It is a shame that the simple uploader can't do simultaneous instances on the same computer, can't do multiple galleries and isn't very robust. It is clear that people doing uploads like you and I are not Smugmug's main design center and not something they feel like they need to design for to have a healthy business.
That's why I went to a third party that did a better job at meeting the need. I'm not stuck with it. If SE breaks and doesn't get fixed quickly, I don't have anything particularly invested in it - no workflow or anything like that. It's just the tool I've found that works the best for me now. I could always just switch to a different tool if something was better at some point. I get your point about FTP offering lots of standard choices for clients - no argument there.
I don't use Smugmug for backup. I've got RAW files and I wanted a fully automatic online uploader tool that analyzes diffs and deltas and just handles updating the backup store automatically. I may be doing something different than you.
I'm sure Smugmug could make ftp work if they were motivated to - they've certainly got the horespower - it's more a matter of whether it's worth it to their business versus all the other things they have to work on.
Look, ftp is NOT consumer friendly - the majority of consumers don't even know what it is or what to do with it. It's for more advanced users.
I tend to disagree with you on this point. Exposure Manager has a much less technical client-base (from what I've gathered), and yet they have FTP already implemented. I think there is a good portion of SM's user base that would use FTP if it was available, especially the pros.
I honestly don't know how it would compare in a head-to-head vs. what they have now in a technology shoot-out, but that isn't really the point.
I know how it compares head-to-head from a workflow standpoint--FTP is fire and forget, 1hr of my time; SM simple uploader, well, it's already been a week and I still have 20% or so to go.
I tend to disagree with you on this point. Exposure Manager has a much less technical client-base (from what I've gathered), and yet they have FTP already implemented. I think there is a good portion of SM's user base that would use FTP if it was available, especially the pros.
That wasn't my point and isn't what I said. My point was that many people don't even know what it is, therefore Smugmug has to have a more built-in option that doesn't require knowing what an FTP client is.
It's a Smugmug business decision whether it's worth their extra effort to ALSO offer an FTP option.
Is the problem that FTP isn't offered, or that HTTP transfers don't support restarting, etc?
For my particular task at hand, restarting doesn't even matter. The main two things that kill my time with the current uploaders is uploading to multiple galleries and using multiple upload streams. With Exposure Manager's FTP implementation, FTP solves these problems for me. It's a very, very, very long road (one that has taken me almost 5 years) with SM's current uploader options.
Ahhh, trying to saturate three cable modems at once - that is a bit of a different requirement than most encounter. When I used to do large uploads on a very, very fast internet connection and not even SE would come close to using the available capacity, I would use 10 simultaneous copies of the older java uploader going at once on the same computer. It is a shame that the simple uploader can't do simultaneous instances on the same computer, can't do multiple galleries and isn't very robust. It is clear that people doing uploads like you and I are not Smugmug's main design center and not something they feel like they need to design for to have a healthy business.
Wow, I think you're the only person on the planet that gets this. I'm actually able to use muliple copies of the simple uploader on the same computer, although when they were initially working on it, it would not do this. Strange that this doesn't work for you.
You and I are rare breeds indeed. This is the bleeding edge of functional computing.
That's why I went to a third party that did a better job at meeting the need. I'm not stuck with it. If SE breaks and doesn't get fixed quickly, I don't have anything particularly invested in it - no workflow or anything like that. It's just the tool I've found that works the best for me now. I could always just switch to a different tool if something was better at some point. I get your point about FTP offering lots of standard choices for clients - no argument there.
SE is an excellent product with excellent support. I highly doubt that it will ever have an issue that isn't quickly resolved, unlike a lot of the other third party uploaders.
I don't use Smugmug for backup. I've got RAW files and I wanted a fully automatic online uploader tool that analyzes diffs and deltas and just handles updating the backup store automatically. I may be doing something different than you.
If I shot primarily in RAW and needed something real-time, I'd have to do something more along your lines. We're definitely having to do different things based on the challenges of the data type, but I think our goal is the same.
I'm sure Smugmug could make ftp work if they were motivated to - they've certainly got the horespower - it's more a matter of whether it's worth it to their business versus all the other things they have to work on.
Totally agree with you. And the purpose of this thread is to put the discussion out there for more people that may be interested in FTP as an uploader.
i read this from the beginning cause i also have some 50k photos to upload and many more coming. the lack of ftp tells me one thing:
The smug people don't implement it as a policy cause they like to make us tired of uploading so instead of occupying precious space and bandwidth we have to upload only the most important stuff.
my job is exactly to make decisions like this in a small company i work, so for me its easy to understand. for example i am new here and intend to upload just 10% of my personal photos because of bandwidth and other issues, like making sure whats up or no, restarting my computer, printing large format- i have to stop the upload cause the PC gets lazy, and so on and so on...
cause with the Filezilla is just too damned easy. i take thousands of photos, put them in the right place and leave the thing. if something is not uploaded it is in a separate place. i can mark all and restart the upload. but easy for me means Difficult for my service provider, in this case Smugmug
so for now i understand their decision if we talk about survival. but just for now. if its not about the surviving is-stubbornness which will lead to further consequences in the future.
and to Andy i say that uploading 125 000 images is not a problem if you do only this, but i have work to do and exactly that's why i subscribed to Smug, to have a work Flow, not spend my precious time with simple up loaders. i believe all agree with this, thats why we are here insisting on ftp, at least for the PRO account.
please people, i am opening this week a second Pro account, i deserve FTP
and what about their Fire uploader ???? i am going to try it and share. for now i try the SE but it still lacks functions that i need and especially changing the properties of Categories, subcategories. cause now if i like to change the properties of a Categorie from Smug i have to choose every gallery one by one. and as i said i will have more than 2000 galleries in the near future
The smug people don't implement it as a policy cause they like to make us tired of uploading so instead of occupying precious space and bandwidth we have to upload only the most important stuff.
This is simply not true.
I'm sorry we don't have FTP options, but we do have many uploading options and plenty of good ways to upload lots of files.
I'm still amazed that 5-6 years into this, Smugmug still doesn't have their own uploader that works robustly and across multiple galleries. You even went and built your own uploader recently and still didn't choose to implement these two important characteristics. It sure does look like you don't want to make it easy for your customers to upload reliably to multiple galleries.
Yes, I use StarExplorer. So, are you telling your customers that if they want a robust uploader that can do multiple galleries, they have to BUY a third party product to do so?
I'm still amazed that 5-6 years into this, Smugmug still doesn't have their own uploader that works robustly and across multiple galleries. You even went and built your own uploader recently and still didn't choose to implement these two important characteristics. It sure does look like you don't want to make it easy for your customers to upload reliably to multiple galleries.
Yes, I use StarExplorer. So, are you telling your customers that if they want a robust uploader that can do multiple galleries, they have to BUY a third party product to do so?
Hey John, it's rather unfair for you to say we don't want to make it easy. It's not like we can wave a magic wand and boom, it's done. You know, more than most people, that we're bootstrapped, family run & owned, and we do everything we can that is possible. We also have a list of things we're executing on regularly. We recently updated our in-browser uploader to make it screaming fast and really reliable.
Making a multiple gallery uploader would be a great idea- and we may do it, but boy is our list ever-long! I'm thankful, that for the really advanced folks that need such an uploader, that there's an option out there for it right now.
Thanks for posting about this, and for saying how important it is to you (and the others posting in this thread, too!).
Hey John, it's rather unfair for you to say we don't want to make it easy. It's not like we can wave a magic wand and boom, it's done.
Questions of multi-gallery uploading not-with-standing, protocols to make sure that a file gets reliably transferred from one point to another have been around since the era of 1200 baud modems, and it's not that hard to develop a transfer protocol that can transparently handle connectivity issues one would expect to find on the internet.
That SM hasn't implemented such a reliable uploader for this absolutely critical function is dumbfounding.
Save $5 off your first year's SmugMug image hosting with coupon code hccesQbqNBJbc
Hey John, it's rather unfair for you to say we don't want to make it easy. It's not like we can wave a magic wand and boom, it's done. You know, more than most people, that we're bootstrapped, family run & owned, and we do everything we can that is possible. We also have a list of things we're executing on regularly. We recently updated our in-browser uploader to make it screaming fast and really reliable.
Making a multiple gallery uploader would be a great idea- and we may do it, but boy is our list ever-long! I'm thankful, that for the really advanced folks that need such an uploader, that there's an option out there for it right now.
Thanks for posting about this, and for saying how important it is to you (and the others posting in this thread, too!).
The reason you haven't done this has nothing to do with being bootstrapped. You've had years and years to do this if you thought it was important. The fact is that you don't think it's a priority and that's where we disagree. I think your priorities are fairly goofed up in this regard and have been for a long time. In the top five most important features on Smugmug should be a robust uploading tool.
I would never consider an uploader fully reliable that isn't coded to seamlessly (without intervention from me) handle temporary network hiccups, Smugmug read-only mode and so on. And, when it is unable to upload something, it should leave that image in a queue ready to go again so I can see EXACTLY what did and didn't upload properly without having to manually sort that out among 1000 images. And, I need one that can upload across many galleries because a sports season upload for me is ~1000 images across 25 galleries. Since I don't have super fast upload speed, I have to do it overnight. Babysitting 25 separate uploads, each one started manually after the previous one is done, is a huge time waster.
I'm blown away that this isn't a priority for Smugmug. It seems way more important and fundamental to robust operation of Smugmug than almost everything listed in uservoice. The uploader you have now is an improvement over what you had before, but it still needs a lot more robustness and needs the ability to do multiple galleries.
And, until you offer something like this, folks will continue to hammer you about not supporting FTP. While I've tried to deflect that criticism for you in the past, I'm done. Smugmug is significantly deficient in the uploader area.
And I had to move a bunch of them from one sub-category to another. Do you know how much of a pain that is with 50 or so galleries? And then deleting another 50 galleries, well, I wrote some html to help me do that.
Pros run into these situations. And sometimes we need pro tools. I usually don't touch more that a few galleries in a work session, but for my archive project, I was working on hundreds.
And, I need one that can upload across many galleries because a sports season upload for me is ~1000 images across 25 galleries. Since I don't have super fast upload speed, I have to do it overnight. Babysitting 25 separate uploads, each one started manually after the previous one is done, is a huge time waster.
Hey John, that is crazy! We've got to figure out why multiple simple uploaders aren't working for you on the same PC. If I had to do this, I'd go crazy.
Here's an interim solution that may work for you. And I still use this method when uploading. I make one gallery and upload everything there. Then, once in SM, I move the files to the various galleries. This way, I can simply set my upload to go, and go to sleep. I wake up the next day, and get to work.
Let me know if there's any way I can help you with uploading strategies. I've had to work around all sorts of limitations in the last 5 years and I'm sure there is a solution that may help you. It's the least I can do for someone who's helped so many SM'ers.
Hey John, that is crazy! We've got to figure out why multiple simple uploaders aren't working for you on the same PC. If I had to do this, I'd go crazy.
Here's an interim solution that may work for you. And I still use this method when uploading. I make one gallery and upload everything there. Then, once in SM, I move the files to the various galleries. This way, I can simply set my upload to go, and go to sleep. I wake up the next day, and get to work.
Let me know if there's any way I can help you with uploading strategies. I've had to work around all sorts of limitations in the last 5 years and I'm sure there is a solution that may help you. It's the least I can do for someone who's helped so many SM'ers.
Thanks for the offer, but I'm not interested in running multiple copies of an unreliable uploader. Try uploading 1000 images across 25 galleries and then be told that you had upload errors with no indication of what the errors actually were and which images didn't properly uploaded into which galleries. Besides making it next to impossible to guarantee that you actually get the images uploaded that you want, it's an enormous time waster to have to figure all that out. This is not a theoretical issue - it has actually happened to me using poor uploaders and has cost me hours of time to sort out.
That's why I use Star Explorer instead. It let's me queue up 1000 images across 25 galleries and it uploads them a couple at a time. If it encounters errors, it does automatic retrying and recovery (I get to control the retry parameters). If it can't upload an image for whatever reason, it leaves it in the upload queue and goes onto the next image. When it's all done, if there were any image upload problems, those images are still in the upload queue are the ones that didn't make it. I just hit Upload again and off they go. I NEVER have to manually figure out which images went and which ones didn't. I NEVER have to wonder what did and didn't upload successfully. If Star Explorer crashes or the computer freezes or the power goes out, the upload queue is even written to disk so the next time I start Star Explorer, it recovers the queue.
My point here is that Smugmug themselves should offer a completely reliable uploader that allows uploads to multiple galleries. It seems like it should be a core competence - made even more important for large videos. I'm glad I've been able to make my point and Andy understands. Hopefully, it will be considered as a priority for development.
Thanks for the offer, but I'm not interested in running multiple copies of an unreliable uploader. Try uploading 1000 images across 25 galleries and then be told that you had upload errors with no indication of what the errors actually were and which images didn't properly uploaded into which galleries. Besides making it next to impossible to guarantee that you actually get the images uploaded that you want, it's an enormous time waster to have to figure all that out. This is not a theoretical issue - it has actually happened to me using poor uploaders and has cost me hours of time to sort out.
I've been there too, in the exact same predicament. Not fun, and I actually gave up on uploading. I forgot that SE works very well for you. If it did for me, I'd probably be using it as well.
My point here is that Smugmug themselves should offer a completely reliable uploader that allows uploads to multiple galleries. It seems like it should be a core competence...
I completely agree. It's almost self-defeating in a way for SM. If I could have uploaded a lot of my images from the past more easily, half of my site's images wouldn't still be hosted off my system at home via a cable modem. And there was a lot of potential for purchases from these older images. I'm just hoping now that as I start to redirect the past galleries to SM, some people will pick out what they wanted and get it.
Comments
Sure. Obviously you have to trust some entities to do anything useful. To even use online banking you're trusting a lot more pieces than an average person realizes (your OS, ISP, browser, DNS infrastructure, Certificate Authorities, etc., etc.). The idea is to minimize the number of pieces involved, compartmentalize, and maximize security of each piece. The fact that I have to trust SM with its own login doesn't mean that I will trust its login to any other piece of closed source software, or that I will trust SM with say login to my online banking.
Filezilla (or any other FTP client) and StarExplorer are on the opposite ends of security risk scale, in my opinion. One is an open source software with many applications and huge user base, many of whom are technical. If there was a backdoor in it, I would expect it to be discovered rather quickly, and it would make the news. Compared to SE with a small user base most of whom are not technical (in a software/security area; I'm sure many are very technical in photography).
This is where you go wrong. They would not need to implement ftp from scratch. Other people already did it, and made the result free and open-source, so that others can benefit. Between free open-source software and SM implementation of uploads via email, SM probably already has all the pieces necessary to make FTP uploads work. They'd need to spend effort on integrating them, testing, UI modifications, etc., but in my opinion it is not much more difficult than making their existing stuff work reliably with all the features, and the result would be much more robust, and require less ongoing maintenance.
My fondness of ftp comes only from the fact that the problem at hand is transferring files reliably, and ftp, being the File Transfer Protocol, is the best solution I know. If we were talking about browsing web content, you'd discover my fondness of http, especially if SM was pushing their own custom implementation in lieu of.
I'll stand by my opinion that I'd rather Smugmug invest in other things than invest in this. That's my opinion and you're welcome to have a different opinion, but I think you're oversimplifying how easy it would be to implement this.
Homepage • Popular
JFriend's javascript customizations • Secrets for getting fast answers on Dgrin
Always include a link to your site when posting a question
You got this backward. It's precisely because they deal with fewer and smaller files that ftp is adding less value for them, and they can live with http or whatever other means they're using.
Look, we both don't want SM wasting resources on unnecessary stuff. To me, reimplementing something that's already been implemented, and reinventing the wheel is the waste. And by the way they're not only wasting their own resources, but also other developers' (although also providing an income stream for some), and the customers'.
As far as oversimplification, I don't think so. Running ftp server is not rocket science. Creating ftp account when a button is clicked in control panel is easily doable, my hosting provider does it from their control panel. Importing files after they've been transfered could be done the same way the mail server does it. What other major components are missing?
Look, ftp is NOT consumer friendly - the majority of consumers don't even know what it is or what to do with it. It's for more advanced users. As such, Smugmug is always going to have other, more consumer friendly, uploading options. Adding ftp is not going to replace anything - just be another uploading technology to support and more work to implement and run. So, I don't buy the argument that it's saving Smugmug any dev time.
I honestly don't know how it would compare in a head-to-head vs. what they have now in a technology shoot-out, but that isn't really the point. They have what they have and they're always going to have an HTTP-based offering for non-ftp savvy folks. So, to me it's really just a matter of whether it's worth adding yet another uploading technology.
Anyway, I think we've exhausted the point of the discussion without knowing a lot more about Smugmug's insides so I'll bow out now.
Homepage • Popular
JFriend's javascript customizations • Secrets for getting fast answers on Dgrin
Always include a link to your site when posting a question
Looking at the wikipedia entry for http transfers, there appears to be a number of ways to support redoing blocks, etc. - http://en.wikipedia.org/wiki/Byte_serving
Do the uploaders do this now? If not, would implementing this give us the restart capability that's needed to make uploads completely bulletproof?
But you also bring up an important point--is a third party solution the ultimate solution? Or does it simply introduce another point of failure in the workflow? How many times has an API change or a SM update broken the third party uploaders? Uploaders that for the most part are made by regular people that volunteered their time to create something, and that may not have time to support it? It's hard to build a solid workflow on a uploader that may fail intermittantly. I've looked into all these solutions, and they don't work for me. Either they lock away data with too many proprietary means of access and retrival, or their uploaders have quirks and overhead that makes them unattractive, besides simply being slow. Uploading all my images to SM accomplishes more than just backup. Thanks to the new smart galleries feature, I'm able to go through and process images from years back as long as they're uploaded just once.
The hard part as been the upload of photos from the previous years. The only way to simultaneous saturate all three of my cable modems (and thereby have the fastest effective upload speed) is to have multiple streams uploading simultaneously. Komodo Drop is the only uploader I've tried that could do this, but it would also crash before all the galleries would complete.
I think the simple uploader would actually work for a large upload if it would be able to handle multiple upload streams simultaneously and have an ability to queue. Functionally, that's all FTP really adds besides universal compatibility.
Want faster uploading? Vote for FTP!
Hmm...I'll have to re-visit SmugBrowser too. It also had crashing issues when I last tried it. But the simultaneous uploads and saturation of bandwidth is exactly what I'm looking for.
Want faster uploading? Vote for FTP!
That's why I went to a third party that did a better job at meeting the need. I'm not stuck with it. If SE breaks and doesn't get fixed quickly, I don't have anything particularly invested in it - no workflow or anything like that. It's just the tool I've found that works the best for me now. I could always just switch to a different tool if something was better at some point. I get your point about FTP offering lots of standard choices for clients - no argument there.
I don't use Smugmug for backup. I've got RAW files and I wanted a fully automatic online uploader tool that analyzes diffs and deltas and just handles updating the backup store automatically. I may be doing something different than you.
I'm sure Smugmug could make ftp work if they were motivated to - they've certainly got the horespower - it's more a matter of whether it's worth it to their business versus all the other things they have to work on.
Homepage • Popular
JFriend's javascript customizations • Secrets for getting fast answers on Dgrin
Always include a link to your site when posting a question
Want faster uploading? Vote for FTP!
It's a Smugmug business decision whether it's worth their extra effort to ALSO offer an FTP option.
Homepage • Popular
JFriend's javascript customizations • Secrets for getting fast answers on Dgrin
Always include a link to your site when posting a question
Want faster uploading? Vote for FTP!
You and I are rare breeds indeed. This is the bleeding edge of functional computing. SE is an excellent product with excellent support. I highly doubt that it will ever have an issue that isn't quickly resolved, unlike a lot of the other third party uploaders. If I shot primarily in RAW and needed something real-time, I'd have to do something more along your lines. We're definitely having to do different things based on the challenges of the data type, but I think our goal is the same. Totally agree with you. And the purpose of this thread is to put the discussion out there for more people that may be interested in FTP as an uploader.
Want faster uploading? Vote for FTP!
http://www.s3fox.net/Features.aspx?isnew=false&from=addon
Want faster uploading? Vote for FTP!
The smug people don't implement it as a policy cause they like to make us tired of uploading so instead of occupying precious space and bandwidth we have to upload only the most important stuff.
my job is exactly to make decisions like this in a small company i work, so for me its easy to understand. for example i am new here and intend to upload just 10% of my personal photos because of bandwidth and other issues, like making sure whats up or no, restarting my computer, printing large format- i have to stop the upload cause the PC gets lazy, and so on and so on...
cause with the Filezilla is just too damned easy. i take thousands of photos, put them in the right place and leave the thing. if something is not uploaded it is in a separate place. i can mark all and restart the upload. but easy for me means Difficult for my service provider, in this case Smugmug
so for now i understand their decision if we talk about survival. but just for now. if its not about the surviving is-stubbornness which will lead to further consequences in the future.
and to Andy i say that uploading 125 000 images is not a problem if you do only this, but i have work to do and exactly that's why i subscribed to Smug, to have a work Flow, not spend my precious time with simple up loaders. i believe all agree with this, thats why we are here insisting on ftp, at least for the PRO account.
please people, i am opening this week a second Pro account, i deserve FTP
I'm sorry we don't have FTP options, but we do have many uploading options and plenty of good ways to upload lots of files.
Portfolio • Workshops • Facebook • Twitter
By reliable, I mean that it automatically deals with temporary upload failures and finishes uploading everything without me having to do anything.
By multiple galleries, I mean an ability to set up one overnight upload session that will put images in multiple galleries.
Homepage • Popular
JFriend's javascript customizations • Secrets for getting fast answers on Dgrin
Always include a link to your site when posting a question
Portfolio • Workshops • Facebook • Twitter
Yes, I use StarExplorer. So, are you telling your customers that if they want a robust uploader that can do multiple galleries, they have to BUY a third party product to do so?
Homepage • Popular
JFriend's javascript customizations • Secrets for getting fast answers on Dgrin
Always include a link to your site when posting a question
Making a multiple gallery uploader would be a great idea- and we may do it, but boy is our list ever-long! I'm thankful, that for the really advanced folks that need such an uploader, that there's an option out there for it right now.
Thanks for posting about this, and for saying how important it is to you (and the others posting in this thread, too!).
Portfolio • Workshops • Facebook • Twitter
That SM hasn't implemented such a reliable uploader for this absolutely critical function is dumbfounding.
I would never consider an uploader fully reliable that isn't coded to seamlessly (without intervention from me) handle temporary network hiccups, Smugmug read-only mode and so on. And, when it is unable to upload something, it should leave that image in a queue ready to go again so I can see EXACTLY what did and didn't upload properly without having to manually sort that out among 1000 images. And, I need one that can upload across many galleries because a sports season upload for me is ~1000 images across 25 galleries. Since I don't have super fast upload speed, I have to do it overnight. Babysitting 25 separate uploads, each one started manually after the previous one is done, is a huge time waster.
I'm blown away that this isn't a priority for Smugmug. It seems way more important and fundamental to robust operation of Smugmug than almost everything listed in uservoice. The uploader you have now is an improvement over what you had before, but it still needs a lot more robustness and needs the ability to do multiple galleries.
And, until you offer something like this, folks will continue to hammer you about not supporting FTP. While I've tried to deflect that criticism for you in the past, I'm done. Smugmug is significantly deficient in the uploader area.
Homepage • Popular
JFriend's javascript customizations • Secrets for getting fast answers on Dgrin
Always include a link to your site when posting a question
Thanks again, John - I'll make sure everyone sees your post on this.
Portfolio • Workshops • Facebook • Twitter
And I had to move a bunch of them from one sub-category to another. Do you know how much of a pain that is with 50 or so galleries? And then deleting another 50 galleries, well, I wrote some html to help me do that.
Pros run into these situations. And sometimes we need pro tools. I usually don't touch more that a few galleries in a work session, but for my archive project, I was working on hundreds.
Want faster uploading? Vote for FTP!
Here's an interim solution that may work for you. And I still use this method when uploading. I make one gallery and upload everything there. Then, once in SM, I move the files to the various galleries. This way, I can simply set my upload to go, and go to sleep. I wake up the next day, and get to work.
Let me know if there's any way I can help you with uploading strategies. I've had to work around all sorts of limitations in the last 5 years and I'm sure there is a solution that may help you. It's the least I can do for someone who's helped so many SM'ers.
Want faster uploading? Vote for FTP!
That's why I use Star Explorer instead. It let's me queue up 1000 images across 25 galleries and it uploads them a couple at a time. If it encounters errors, it does automatic retrying and recovery (I get to control the retry parameters). If it can't upload an image for whatever reason, it leaves it in the upload queue and goes onto the next image. When it's all done, if there were any image upload problems, those images are still in the upload queue are the ones that didn't make it. I just hit Upload again and off they go. I NEVER have to manually figure out which images went and which ones didn't. I NEVER have to wonder what did and didn't upload successfully. If Star Explorer crashes or the computer freezes or the power goes out, the upload queue is even written to disk so the next time I start Star Explorer, it recovers the queue.
My point here is that Smugmug themselves should offer a completely reliable uploader that allows uploads to multiple galleries. It seems like it should be a core competence - made even more important for large videos. I'm glad I've been able to make my point and Andy understands. Hopefully, it will be considered as a priority for development.
Homepage • Popular
JFriend's javascript customizations • Secrets for getting fast answers on Dgrin
Always include a link to your site when posting a question
Want faster uploading? Vote for FTP!