From mboxrd@z Thu Jan 1 00:00:00 1970 From: andy at warmcat.com (Andy Green) Date: Wed, 4 Jul 2018 08:44:18 +0800 Subject: [PATCH] native inline gravatar In-Reply-To: References: <153041523536.31775.12330787152148492370.stgit@mail.warmcat.com> Message-ID: <569ca21d-c5f7-a273-d5eb-f5fed50f5f0a@warmcat.com> On 07/04/2018 08:34 AM, Jason A. Donenfeld wrote: > On Wed, Jul 4, 2018 at 2:28 AM Andy Green wrote: >> I looked at it, but there's no md5 api in JS... you have to do it by >> hand in JS. It's possible but I think it might be slow if it hits a >> page of 50 different email addresses. > > MD5 is really fast and fits easily into javascript's integer types. > There should be reasonably fast implementations available. > Alternatively, you could generate asm.js and web assembly code using > something like emscripten. > >> Is it supported to do the job of pygments in Lua? > > You can do any type of text processing you want from Lua. If you'd > like to contribute a Lua highlighter, that'd be quite nice. > >> What it does today is spawn the python runtime, start that up etc. > > Have you measured latency issues with this? Nope, but it's obviously more efficient to not be spawning python apps. Don't you think? >> I know... bandwidth and server compute time. >> >> Also there's no reason (other than not enough care taken with frees atm) >> cgit should only be buildable as a cgi starting up its own process each >> time. > > You're talking about FastCGI support? I have no idea how this is > related to the current line of discussion -- perhaps just by being > another gripe or something -- but this is actually something we've What was the first gripe? I am providing patches for all these things not moaning about them. I mention it because starting up cgit as a process each time is also overhead, I think it would be interesting also to look at eliminating that. > looked at in depth. (See the list archives.) Our last conclusion from > examining it was that so much of libgit is not re-entrant, and so we'd > need to move to something like libgit2 for this to be feasible. Too > many globals, etc. Let me guess, not enough people around working on this project, for some reason, to move to libgit2. >> It could optionally link against OpenSSL then :-) It can optionally >> link against lua. >> >> If you're not interested in going where this stuff is going, you can >> save us both a lot of time by just saying it now, and I'll stop trying >> to sell it here. > > I made that clear in my very first message to you: > > "Sorry, but not a chance something like this can be accepted." If that's your feeling about the whole stack of clientside stuff, I understand you don't want to cooperate on it. No worries I'll leave you to it then. -Andy