methinks CGI, because the ``secret'' isn't even kept (too much misinformation) and it's not even secret: instead of serving data of a file, serving data of output of an executable (with a way to input (i.e. reading (and parsing formatted) stdin, and special environment variables), and a small restriction regarding output (i.e. Content-type: X/Y\n\n))
Is there not slant formatting in headline?
>>2
Italic markup is handled in lib/markup.scm:italic. The called-by graph can be traced as italic => line-scanner => [format-paragraph, rformat-paragraph] => [format-blockquote, markup->sxml] => [markup->sxml .] which unifies as lib/markup.scm:markup->sxml. This switches to bbs.scm in [post-message, post-thread]. The former handles posting messages within a thread and has no concept of headline. The latter handles new threads and has a let* that includes:
(message (decode-formdata (lookup-def 'epistula params)))
(headline (decode-formdata (lookup-def 'titulus params)))The markup->sxml call is in the next let* as:
(sxml (markup->sxml message board (number->string thread-number))))So the headline is never subjected to markup->sxml and therefore neither to italic.
has no concept of headline
So? It's just text. Text and text formatting. To apply text formatting to text, one not need consider whether it's headline.
>>4
What he's trying to say is that the function that formats text does not consider headline on it.
>>4,5
It's not a big deal. Underscores are often used in plain text to mark an emphasis, so, the lack of formatting your headline degraded gracefully.
CGI starts a new process every time it's invoked which is expansive. FastCGI is a complex protocol. In the end it's simpler to parse the http request directly.
>>6
As I understand it, CGI works thusly:
HTTP_client -HTTP_request-> HTTP_server -CGI_request-> CGI_server -program_request-> program -program_result-> CGI_server -CGI_result-> HTTP_server -HTTP_result> HTTP_client.
The expensiveness of CGI was in that it started a new instance of the CGI server for each CGI request, and terminated it as soon as it gave out the result. FastCGI is the same as CGI, but it stays running, listening for new CGI requests, even after it's done giving out the results of all extant requests.
In the end it's simpler to parse the http request directly.
Perhaps in some cases. Some persons may misinterpret such a statement as a generality. Also, what had you meant by ``parse the http request directly''? Perhaps you had meant that the end program, instead of httpd, should do the work of talking the HTTP protocol, listening on various ports, handling the traffic,, as well as doing the work to generate the HTTP result. That would be the direct interpretation of ``parse the http request directly'', but that is not good general advice. Perhaps in some cases, it is more efficient.
Perhaps you meant that httpd should just serve static files. That would be sane default advice.
Perhaps you meant that httpd should just serve static files. That would be sane default advice.
I understand your point but httpd is supposed to serve resources, which as far as I know were never defined as merely static files. Let's forget for a while the abomination of the use of a web browser as a universal virtual machine to run anything (there, I'm sure we share the same point of view). There's nothing wrong with dynamically generated content: statistics, lists of recently updated contents etc.
As I understand it, CGI works thusly:
HTTP_client -HTTP_request-> HTTP_server -CGI_request-> CGI_server -program_request-> program -program_result-> CGI_server -CGI_result-> HTTP_server -HTTP_result> HTTP_client.
What I was trying to argue is that transforming the HTTP requests into a CGI request might be an unnecessary step and is now frequently replaced with :
HTTP_client -HTTP_request-> HTTP_server -HTTP_request(forwarded) -> "Application Server" -program_request-> program -program_result-> "Application Server" -HTTP_result-> HTTP_server -HTTP_result (forwarded, eventually reformated) -> HTTP_client.
Do you really need to translate HTTP requests into CGI requests? Is it a necessary step? Requests forwarded from the HTTP server ought to be clean and consistent enough and you really don't have to implement the whole HTTP specs into your application server.
What follows might need a trigger warning because that's absolutely against the elementary separation of concepts and I have a feeling that you're not going to appreciate it much. You can even use the web server itself to serve dynamic content. Lua is trivial to embed in a C server and when you're looking at raw performance, this way of building things has proven to be very efficient. Chinese programmers are into this. We didn't have a lot of code coming from them on github before that. Take a look at the OpenResty project for instance: https://openresty.org/en/ You have the fast non blocking event loop of nginx and the ability to generate dynamic content with the speed of LuaJIT. Why not building web applications this way, if you have to deal with huge loads? That's the solution Alibaba, the giant chinese marketplace came up with.
Under really high load you can come up with even more radical approaches like embedding a primitive web server into your content application: (and here's another chinese project that I found "inspiring")
https://github.com/ellzey/libevhtp
sample application: https://github.com/buaazp/zimg
6
the lack of formatting your headline degraded gracefully.
This forum being slow, concurrent visitors are unlikely. >>2 was published (I assume the time displayed is the time of publication of the post) within minutes (2019-12-26 22:32--34) of >>1. The author of >>1 and the author of >>2 are probably only one person. Assuming that >>1 and >>2 are idemauteuric, his saying ``Is there not slant formatting in headline?'', would seem to suggest that he would have preferred to omit target-text underscore-based formatting, perhaps on aesthetic grounds. I know certainly that 1 such person exists. So the lack of formatting in his headline may have degraded, though gracefully, illy.
absolutely against the elementary separation of concepts ... use the web server itself to serve dynamic content ... very efficient.
(I hope I didn't thereby garble.) It's not so much they're nonseparated, but separations being in source, where a nonprogrammer might not look. People rail against ``monolitic'' design/implementation, but if the code is modular (abstract libraries etc), it's fine. Ofcourse, nonprogrammers not can easily change it, but that might be OK for the goal e.g. business website (as you mentioned) not changing much not needs ``user''-modularity. Further, maybe see ``literate programming,'' which keeping concepts separated, but implementation integrated. (Idea is write fully description for programmers, users,, (intelligent (or not-so) agents to whom germane) interjected with computer instructions formate to compile) Doing rightly, even smallers benefit, less resource and less maintainence/inscrutibility.
>>8
It's too bad there isn't a production HTTP server with a Cap'n Proto or similar interface. That Libevhtp project is interesting.
>>10
>>8-kun probably isn't here anymore.
>>11
Why not a restricted sexpr daemon instead of a http daemon? I know >>1-san doesn't make the separation from www and the global darpa catenet but diverting further seams what >>8-kun wants, it would keep the universal virtual machine disaster from happening by having an interpreter instead but it isn't really that much better since the wwwasm top level virtual machine already "interprets" a variant of the nonexistent markup language and css for rending, imo.
What is this "kun" thing?
What's the internet's worst kept secret?
User surveillance and profiling.
>>14
this
-kun is often used as a suffix when calling someone. The listener is lower or the same level in social position and is often, but not always, male.
Six stage of Debugging
Denial->That can't Happen
Anger->That doesn't happen on My Machine.
Bargaining->That shouldn't happen
Depression-> Why does that happen?
Acceptance->Oh i see.
Confusion->How did that ever work?
>>17 Six stages of debugging proven code:
Denial: My code can't have bugs, it's proven.
Anger: Go bother some other git!
Bargaining: Look, if you stop harassing me, I'll not press charges.
Depression: Why do I know all these idiots?
Acceptance: If they accept edifaction, I'll have to just ignore them.
Confusion: How does this industry not fall apart?
Excuse my error: if the *don't* accept edifaction
Copyright is joke
But even the jokes are copyrighted