πΎ Archived View for gemi.dev βΊ gemini-mailing-list βΊ 000272.gmi captured on 2024-08-19 at 00:03:24. Gemini links have been rewritten to link to archived content
β¬ οΈ Previous capture (2023-12-28)
-=-=-=-=-=-=-
I read a very interesting discussion between Petite Abeille, Solderpunk, Luke Emmet 2-3 weeks ago, regarding how to upload small content to Gemini servers (eg. wiki page updates, comments,...) The idea revolves around using the URL to upload small content (or chunked content in several requests) Petite Abeille gemini://gemi.dev/gemini-mailing-list/messages/001644.gmi Solderpunk reply gemini://gemi.dev/gemini-mailing-list/messages/001672.gmi and Luke Emmet gemini://gemi.dev/gemini-mailing-list/messages/001681.gmi Quoting Solderpunk: >Well, look - 1024 bytes as a maximum URL length is a value I more or less plucked out of the air without deep consideration, simply because the elements passed around by a protocol *should* have a well-defined maximum length so people can allocate appropriately sized memory buffers, etc. I certainly *wasn't* thinking about using queries to upload content, I was thinking of "ordinary URLs" and so 1024 bytes seemed hugely generous. > According to GUS, currently more than half of the text/gemini content out there is less than 1.2 KiB in size. If URLs were allowed to be 2048 bytes long, all that content could be uploaded as a query. > Can we solve a lot of these issues by bumping up our maximum URL length? I suggest bumping the URL maximum length to 8KB. - it allows creative uses of _mechanisms already in place_ in Gemini, - it doesn't change the definition of the protocol and protocol elements, - it doesn't impact existing clients, - the impact on existing servers is very limited (allocating a 8K instead of 1K buffer...), and an existing server should just refuse too long a request. - 8K vs 1K doesn't make a difference for a client today in terms of RAM footprint - after all, let's not forget that TLS is mandatory here ;-) What do you think? Phil
On Sat, Jul 04, 2020 at 07:17:37PM +0000, Phil Leblanc wrote: > > Can we solve a lot of these issues by bumping up our maximum URL length? > > I suggest bumping the URL maximum length to 8KB. > > - it allows creative uses of _mechanisms already in place_ in Gemini, > - it doesn't change the definition of the protocol and protocol elements, > - it doesn't impact existing clients, > - the impact on existing servers is very limited (allocating a 8K > instead of 1K buffer...), and an existing server should just refuse > too long a request. > - 8K vs 1K doesn't make a difference for a client today in terms of > RAM footprint - after all, let's not forget that TLS is mandatory here > ;-) I'm still open to something like this. And for the record, I still think the idea of "uploading by hosting" and passing the URL used for that in response to a status code 10 is too beautiful not to explore, if we really, really need to be able to upload in band. I get that not everybody can host publically, but this could be worked around in various ways: pubnixes could offer this facility to their users. Somebody could setup a lightweight public web upload point which then rehosted the resource one a one-use Gemini URL - Sloum has already demonstrated with gemlog.blue how this kind of thing can work. Cheers, Solderpunk
On Sat, Jul 4, 2020 at 9:33 PM solderpunk <solderpunk at sdf.org> wrote: > > > Can we solve a lot of these issues by bumping up our maximum URL length? > > I'm still open to something like this. And for the record, I still > think the idea of "uploading by hosting" and passing the URL used for > that in response to a status code 10 is too beautiful not to explore, if > we really, really need to be able to upload in band. A longer URL doesn't prevent at all exploring / implementing the uploading by hosting approach. It only addresses some use cases where the existing input mechanism can be used as-is (e.g. comments, small document updates). I think it could also be useful for simple gemini applications, typically the applications "by me, for me" you describe here =>gemini://gemini.circumlunar.space/users/solderpunk/cornedbeef/a-vision-fo r-gemini-applications.gmi It is _not_ a modification in any way of the Gemini protocol - Just a different size limit. Phil
On Sat, Jul 04, 2020 at 09:59:23PM +0000, Phil Leblanc wrote: > On Sat, Jul 4, 2020 at 9:33 PM solderpunk <solderpunk at sdf.org> wrote: > > A longer URL doesn't prevent at all exploring / implementing the > uploading by hosting approach. It only addresses some use cases where > the existing input mechanism can be used as-is (e.g. comments, small > document updates). > > It is _not_ a modification in any way of the Gemini protocol - Just a > different size limit. Sure, I get all that, didn't mean to imply otherwise. Just doing "my thing" of urging people to think hard about and perhaps even actually implement and test solutions to problems which don't involve extension/modification in preference to those which do... Cheers, Solderpunk
---