>> From: "Salvador \"Fandiño\" via RT" <bug-Net-SFTP-Foreign@rt.cpan.org>
>> To:
>> Cc:
>> Sent: Thursday, February 19, 2015 8:01 PM
>> Subject: Re: [rt.cpan.org #102216] Wish: transparent solution for transfer directories and IO::All
>>
>> Queue: Net-SFTP-Foreign
>> Ticket <URL:
https://rt.cpan.org/Ticket/Display.html?id=102216 >
>>
>>
>>
>>
>>
>>
>> ----- Original Message -----
>>> From: Jens Rehsack via RT <bug-Net-SFTP-Foreign@rt.cpan.org>
>>> To:
>>> Cc:
>>> Sent: Thursday, February 19, 2015 7:00 PM
>>> Subject: Re: [rt.cpan.org #102216] Wish: transparent solution for transfer
>> directories and IO::All
>>>
>>> Queue: Net-SFTP-Foreign
>>> Ticket <URL:
https://rt.cpan.org/Ticket/Display.html?id=102216 >
>>>
>>>
>>>> Am 19.02.2015 um 17:35 schrieb Salvador Fandiño via RT
>>> <bug-Net-SFTP-Foreign@rt.cpan.org>:
>>>>
>>>> <URL:
https://rt.cpan.org/Ticket/Display.html?id=102216 >
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> ----- Original Message -----
>>>>> From: Jens Rehsack via RT <bug-Net-SFTP-Foreign@rt.cpan.org>
>>>>> To:
>>>>> Cc:
>>>>> Sent: Thursday, February 19, 2015 3:07 PM
>>>>> Subject: [rt.cpan.org #102216] Wish: transparent solution for
>> transfer
>>> directories and IO::All
>>>>>
>>>>> T hu Feb 19 09:07:31 2015: Request 102216 was acted upon.
>>>>> Transaction: Ticket created by REHSACK
>>>>> Queue: Net-SFTP-Foreign
>>>>> Subject: Wish: transparent solution for transfer directories
>> and
>>> IO::All
>>>
>>>>>
>>>>>
>>>>> Hi,
>>>>>
>>>>> thanks for Net::SFTP::Foreign \o/
>>>>>
>>>>> In a customer project I encountered the situation that I'd
>> like to
>>> handle
>>>>> the I/O layer of a process using IO::All, because the
>> sources/targets
>>> reach from
>>>>> file over restful to sftp. So I'd start playing with
>> IO::All::SFTP
>>> (based on
>>>>> LWP::Protocol::sftp based on Net::SFTP::Foreign).
>>>>>
>>>>> On key requirement when putting a file via sftp in the transfer
>>> directory
>>>>> situation is, that the file initially has to be written into a
>>> temporary
>>>>> location, flushed and finally renamed to the correct location.
>>>>
>>>>
>>>> If I undestand your requirements correcly, that is what the
>>> "atomic" feature on the put method already does.
>>>>
>>>> You can also use just a "put" followed by a
>> "rename" or
>>> "atomic_rename" operation.
>>>
>>> I didn't realize that - yes, that would solve the issue. Maybe an
>> atomic
>>> template would help to execute such a combination of operations through an
>>> IO::All operation. The benefit of IO::All (and also IO::All::SFTP) is the
>> fact
>>> that AnyData can write encoded data directly to the target environment.
>>>
>>>>> Given that you accept the challenge to enhance Net::SFTP::Foreign
>> or
>>>>> LWP::Protocol::sftp (please feel free to move the ticket to
>> another
>>> queue where
>>>>> it's appropriate) to support that wish - what would the best
>>> strategy?
>>>>>
>>>>> * add on_close callback/shell-code to Net::SFTP::Foreign
>>>>> * add write_to_tmp_location bool as session parameter
>>>>> * add explicit logic to LWP::Protocol::sftp for renaming from
>> temporary
>>>
>>>>> directory (parameter!)?
>>>>>
>>>>> As far as I understood LWP::Protocol::sftp, the last one is the
>> less
>>> favored
>>>>> idea ;)
>>>>
>>>>
>>>> Probably it was not a good idea to use LWP::Protocol::sftp as an
>>> intermediate layer between IO::All and Net::SFTP::Foreign in the first
>> place!
>>>
>>> Do you have a better suggestion? Mind that IO::All has enormous benefits
>> because
>>> of the transparency of the IO-implementation.
>>
>>
>> I don't know anything about IO:All internals or specifically how new
>> backends can be plugged, but from the outside it seems to me that IO::All
>> provides a feature rich API that more or less models a file system and the same
>> is true for Net::SFTP::Foreign. On the other hand, LWP::Protocol::sftp provides
>> a very narrow API that only supports a few basic operations (IIRC, get, put and
>> ls), so it doesn't seem like a good idea to have it in the middle.
>>
>> I suppose the rigth way to support SFTP in IO::All would be to write a direct
>> adapter for Net::SFTP::Foreign that could take advantage of most of its
>> features.
>>
