On 3/29/20 9:24 PM, Magnus Hagander wrote:
> On Sun, Mar 29, 2020 at 9:08 PM Stephen Frost <sfrost@snowman.net> wrote:
>>
>> Greetings,
>>
>> * Stefan Kaltenbrunner (stefan@kaltenbrunner.cc) wrote:
>>> On 3/26/20 3:44 PM, Magnus Hagander wrote:
>>>> We could put it just to the right of the download link though? There
>>>> seems to be enough space for that with a large margin at least on
>>>> desktops.
>>>
>>> what about doing something completely different - like hiding those
>>> links behind community auth and call it a day(especially with so few users)?
>>>
>>> I dont see a problem with requiring community auth for downloading those
>>> links as well as raw messages..
>>
>> I guess the question there is- how hard would it be for someone to
>> script the community auth process, so that they can automatically
>> download the mbox's each month, if they wish to..?
>
> Complicated enough that a process like that is going to be *really* annoying.
if we are just talking about providing a monthly mbox file to download
we could probably just provide a completely different way to provide
that data that does not involve dynamically generating it in real-time...
>
>
>> I'm guessing it's probably not that hard, but that's the one thing that
>> comes to mind regarding this proposal.. Otherwise I am generally in
>> support of requiring community auth for this instead of using the basic
>> auth method we have today.
>
> One of the original usecases for "download thread as mbox" was you, I
> believe , which was basically about opening a mailbox directly from
> inside mutt or something? Isn't that also going to be a lot more
> annoying from something like this?
I dont understand that argument - so mutt directly does http and http
basic auth or what is the usecase? If it is just clicking in your
browser and have that link fed into mutt by means of mime-type or file
extension detection that would just work as before...
Stefan