~sircmpwn/public-inbox

3 2

gddo: provide a gemini end-point

Details
Message ID
<CAA1FBEUQ6N0.O32RRC4V7HOS@zoidberg>
DKIM signature
pass
Download raw message
hi there,

I was writing a talk about Gemini and toying a bit with the idea of
providing a Gemini end-point for godocs.io.

I have something working over there:

- git.sr.ht/~sbinet/griket

It isn't yet super polished but before I actually shape it up a bit, I
figured I should ask here whether that's something useful enough to
provide cleaned up patches against ~sircmpwn/gddo.

Right now, it's handling examples in a quite ad hoc way: as these
examples may well be quite lengthy (and as IIUC there isn't a way to
toggle/hide parts of gemini page), examples are not displayed unless a
query parameter "?ex=1" is requested.
If that query parameter isn't present, the Gemini page will generate a
local line-link at the top with that parameter tacked onto the URL:

=> /my/pkg?ex=1 Show examples

Suggestions welcomed, of course, for a better handling of those "pesky"
examples.

-s
Details
Message ID
<CAA1I0USM73D.4MLM6OH59PD9@taiga>
In-Reply-To
<CAA1FBEUQ6N0.O32RRC4V7HOS@zoidberg> (view parent)
DKIM signature
fail
Download raw message
DKIM signature: fail
I would definitely be interested in having Gemini support upstream. I
think that the ?ex=1 parameter is a good solution to the examples issue.
There should be a link available on the page which toggles these on and
off.
Details
Message ID
<CAAOMVE5HHR1.15JKGL8B3Y4AH@zoidberg>
In-Reply-To
<CAA1I0USM73D.4MLM6OH59PD9@taiga> (view parent)
DKIM signature
fail
Download raw message
DKIM signature: fail
On Mon Mar 29, 2021 at 20:17 CET, Drew DeVault wrote:
> I would definitely be interested in having Gemini support upstream. I
> think that the ?ex=1 parameter is a good solution to the examples issue.
> There should be a link available on the page which toggles these on and
> off.

great!

how do envision the architecture?
I was thinking about adding the gemini part directly to `gddo-serve` and,
more precisely, split the `server` type into 3 parts:
- db/crawling-related stuff
- http-related stuff
- gmni-related stuff

ie:

type server struct {
	v          *viper.Viper
	db         *database.Database
	httpClient *http.Client

	hsrv struct {
		templates templateMap

		statusPNG http.Handler
		statusSVG http.Handler

		root rootHandler
	}

	// A semaphore to limit concurrent ?import-graph requests.
	importGraphSem chan struct{}

	gsrv struct {
		root rootGmniHandler
	}
}

func (s *server) ServeGemini(ctx context.Context, w gemini.ResponseWriter, r *gemini.Request) {
	s.gsrv.root.ServeGemini(ctx, w, r)
}

`hsrv` and `gsrv` could become dedicated types (with hsrv probably
swallowing a few http-related methods that live currently in `server`.


or, one could just tack on the Gemini part as a rather standalone thing,
with just a few interactions with the original server part (sync/lock
of the db and crawler to request doc.Package values).

or, a completely different `main`, but sharing the same db beneath all.

WDYT?

-s
Details
Message ID
<CAAOP9QTUDJ1.2BRIJLZGDTJ7D@taiga>
In-Reply-To
<CAAOMVE5HHR1.15JKGL8B3Y4AH@zoidberg> (view parent)
DKIM signature
fail
Download raw message
DKIM signature: fail
On Tue Mar 30, 2021 at 8:25 AM EDT, Sebastien Binet wrote:
> On Mon Mar 29, 2021 at 20:17 CET, Drew DeVault wrote:
> > I would definitely be interested in having Gemini support upstream. I
> > think that the ?ex=1 parameter is a good solution to the examples issue.
> > There should be a link available on the page which toggles these on and
> > off.
>
> great!
>
> how do envision the architecture?
> I was thinking about adding the gemini part directly to `gddo-serve`
> and,
> more precisely, split the `server` type into 3 parts:
> - db/crawling-related stuff
> - http-related stuff
> - gmni-related stuff

Yeah, this works for me.
Reply to thread Export thread (mbox)