Alan McKinnon <alan.mckin...@gmail.com> writes: > On 30/04/2017 03:11, lee wrote: >> "Poison BL." <poiso...@gmail.com> writes: >> >>> On Sat, Apr 29, 2017 at 3:24 PM, lee <l...@yagibdah.de> wrote: >>> >>>> Mick <michaelkintz...@gmail.com> writes: >>>> >>>>> On Tuesday 25 Apr 2017 16:45:37 Alan McKinnon wrote: >>>>>> On 25/04/2017 16:29, lee wrote: >>>>>>> Hi, >>>>>>> >>>>>>> since the usage of FTP seems to be declining, what is a replacement >>>>>>> which is at least as good as FTP? >>>>>>> >>>>>>> I'm aware that there's webdav, but that's very awkward to use and >>>>>>> missing features. >>>>>> >>>>>> Why not stick with ftp? >>>>>> Or, put another way, why do you feel you need to use something else? >>>>>> >>>>>> There's always dropbox >>>>> >>>>> >>>>> Invariably all web hosting ISPs offer ftp(s) for file upload/download. >>>> If you >>>>> pay a bit more you should be able to get ssh/scp/sftp too. Indeed, many >>>> ISPs >>>>> throw in scp/sftp access as part of their basic package. >>>>> >>>>> Webdav(s) offers the same basic upload/download functionality, so I am >>>> not >>>>> sure what you find awkward about it, although I'd rather use lftp >>>> instead of >>>>> cadaver any day. ;-) >>>>> >>>>> As Alan mentioned, with JavaScript'ed web pages these days there are many >>>>> webapp'ed ISP offerings like Dropbox and friends. >>>>> >>>>> What is the use case you have in mind? >>>> >>>> transferring large amounts of data and automatization in processing at >>>> least some of it, without involving a 3rd party >>>> >>>> "Large amounts" can be "small" like 100MB --- or over 50k files in 12GB, >>>> or even more. The mirror feature of lftp is extremely useful for such >>>> things. >>>> >>>> I wouldn't ever want having to mess around with web pages to figure out >>>> how to do this. Ftp is plain and simple. So you see why I'm explicitly >>>> asking for a replacement which is at least as good as ftp. >>>> >>>> >>>> -- >>>> "Didn't work" is an error. >>>> >>>> >>> Half petabyte datasets aren't really something I'd personally *ever* trust >>> ftp with in the first place. >> >> Why not? (12GB are nowhere close to half a petabyte ...) >> >>> That said, it depends entirely on the network >>> you're working with. Are you pushing this data in/out of the network your >>> machines live in, or are you working primarily internally? If internal, >>> what're the network side capabilities you have? Since you're likely already >>> using something on the order of CEPH or Gluster to back the datasets where >>> they sit, just working with it all across network from that storage would >>> be my first instinct. >> >> The data would come in from suppliers. There isn't really anything >> going on atm but fetching data once a month which can be like 100MB or >> 12GB or more. That's because ppl don't use ftp ... > > I have the opposite experience. > I have the devil's own time trying to convince people to NOT use ftp for > anything and everything under the sun that even remotely resembles > getting data from A to B...
I guess you're lucky then. > (especially things that are best done over a > message bus) Why would anyone try to transfer data over a message bus? Doesn't that require extra wiring and specialized hardware? > I'm still not understanding why you are asking your questions. What you > describe looks like the ideal case for ftp: it is Still nobody uses it, and apparently ftp usage is generally declining, so I would expect there to be a better alternative. > > - supplier pushes a file or files somewhere > - you fetch those files later at a suitable time > > it looks like a classic producer/consumer scenario and ftp or any of > it's webby clones like dropbox really it still the best tool overall. > Plus it has the added benefit that no user needs extra software - all > OSes have ftp clients even if it's just a browser The users don't know about that. -- "Didn't work" is an error.
