1 |
On 30/04/2017 03:11, lee wrote: |
2 |
> "Poison BL." <poisonbl@×××××.com> writes: |
3 |
> |
4 |
>> On Sat, Apr 29, 2017 at 3:24 PM, lee <lee@××××××××.de> wrote: |
5 |
>> |
6 |
>>> Mick <michaelkintzios@×××××.com> writes: |
7 |
>>> |
8 |
>>>> On Tuesday 25 Apr 2017 16:45:37 Alan McKinnon wrote: |
9 |
>>>>> On 25/04/2017 16:29, lee wrote: |
10 |
>>>>>> Hi, |
11 |
>>>>>> |
12 |
>>>>>> since the usage of FTP seems to be declining, what is a replacement |
13 |
>>>>>> which is at least as good as FTP? |
14 |
>>>>>> |
15 |
>>>>>> I'm aware that there's webdav, but that's very awkward to use and |
16 |
>>>>>> missing features. |
17 |
>>>>> |
18 |
>>>>> Why not stick with ftp? |
19 |
>>>>> Or, put another way, why do you feel you need to use something else? |
20 |
>>>>> |
21 |
>>>>> There's always dropbox |
22 |
>>>> |
23 |
>>>> |
24 |
>>>> Invariably all web hosting ISPs offer ftp(s) for file upload/download. |
25 |
>>> If you |
26 |
>>>> pay a bit more you should be able to get ssh/scp/sftp too. Indeed, many |
27 |
>>> ISPs |
28 |
>>>> throw in scp/sftp access as part of their basic package. |
29 |
>>>> |
30 |
>>>> Webdav(s) offers the same basic upload/download functionality, so I am |
31 |
>>> not |
32 |
>>>> sure what you find awkward about it, although I'd rather use lftp |
33 |
>>> instead of |
34 |
>>>> cadaver any day. ;-) |
35 |
>>>> |
36 |
>>>> As Alan mentioned, with JavaScript'ed web pages these days there are many |
37 |
>>>> webapp'ed ISP offerings like Dropbox and friends. |
38 |
>>>> |
39 |
>>>> What is the use case you have in mind? |
40 |
>>> |
41 |
>>> transferring large amounts of data and automatization in processing at |
42 |
>>> least some of it, without involving a 3rd party |
43 |
>>> |
44 |
>>> "Large amounts" can be "small" like 100MB --- or over 50k files in 12GB, |
45 |
>>> or even more. The mirror feature of lftp is extremely useful for such |
46 |
>>> things. |
47 |
>>> |
48 |
>>> I wouldn't ever want having to mess around with web pages to figure out |
49 |
>>> how to do this. Ftp is plain and simple. So you see why I'm explicitly |
50 |
>>> asking for a replacement which is at least as good as ftp. |
51 |
>>> |
52 |
>>> |
53 |
>>> -- |
54 |
>>> "Didn't work" is an error. |
55 |
>>> |
56 |
>>> |
57 |
>> Half petabyte datasets aren't really something I'd personally *ever* trust |
58 |
>> ftp with in the first place. |
59 |
> |
60 |
> Why not? (12GB are nowhere close to half a petabyte ...) |
61 |
> |
62 |
>> That said, it depends entirely on the network |
63 |
>> you're working with. Are you pushing this data in/out of the network your |
64 |
>> machines live in, or are you working primarily internally? If internal, |
65 |
>> what're the network side capabilities you have? Since you're likely already |
66 |
>> using something on the order of CEPH or Gluster to back the datasets where |
67 |
>> they sit, just working with it all across network from that storage would |
68 |
>> be my first instinct. |
69 |
> |
70 |
> The data would come in from suppliers. There isn't really anything |
71 |
> going on atm but fetching data once a month which can be like 100MB or |
72 |
> 12GB or more. That's because ppl don't use ftp ... |
73 |
|
74 |
I have the opposite experience. |
75 |
I have the devil's own time trying to convince people to NOT use ftp for |
76 |
anything and everything under the sun that even remotely resembles |
77 |
getting data from A to B... (especially things that are best done over a |
78 |
message bus) |
79 |
|
80 |
I'm still not understanding why you are asking your questions. What you |
81 |
describe looks like the ideal case for ftp: |
82 |
|
83 |
- supplier pushes a file or files somewhere |
84 |
- you fetch those files later at a suitable time |
85 |
|
86 |
it looks like a classic producer/consumer scenario and ftp or any of |
87 |
it's webby clones like dropbox really it still the best tool overall. |
88 |
Plus it has the added benefit that no user needs extra software - all |
89 |
OSes have ftp clients even if it's just a browser |
90 |
|
91 |
-- |
92 |
Alan McKinnon |
93 |
alan.mckinnon@×××××.com |