💾 Archived View for rawtext.club › ~sloum › geminilist › 000367.gmi captured on 2020-11-07 at 01:26:27. Gemini links have been rewritten to link to archived content

View Raw

More Information

⬅️ Previous capture (2020-09-24)

-=-=-=-=-=-=-

<-- back to the mailing list

File size issues

solderpunk solderpunk at SDF.ORG

Sat Jan 18 17:48:49 GMT 2020

- - - - - - - - - - - - - - - - - - - ```

On Sun, Aug 18, 2019 at 11:36:41AM +0000, solderpunk wrote: 
> Yeah, I think we can leave this for now.  It was a hypothetical concern
> that somebody had.  Not necessarily a bad one, but until it's observed
> actually creating significant trouble for actual users on actual clients
> I think we can just table this issue.  If it does come up as a practical
> concern, we can resume discussion of some of the ideas here.

Well, I guess this is no longer quite so hypothetical, as Konpeito hasgiven us large binary files over Gemini.  I noticed that this was anunpleasant user experience to download via AV-98 (with the clientappearing to "hang" for a long time during the download).  And, in fact,I did receive an email from one person telling me they liked Gemini alot, who mentioned that they had not been able to download the Konpeitoalbum.  I strongly suspect that, in fact, they just didn't realise theirclient was slowly downloading it.

One possible solution to the user experience problem that doesn'trequire the client actually knowing the file size is to display, insteadof a progress bar, some kind of "stuff is happening" indicator, e.g. ananimated spinner (you know, of the /, -, \, | kind) accompanied by a count of KiB / MiB downloaded so far?  That would at least make itobvious to users that something was happening.

And a convention of specifying filesizes for large binary files in thelink text would allow rough mental calculation of progress?

Cheers,Solderpunk