From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp-2.sys.kth.se (smtp-2.sys.kth.se [130.237.32.160]) by krisdoz.my.domain (8.14.3/8.14.3) with ESMTP id pAONF9ru016008 for ; Thu, 24 Nov 2011 18:15:09 -0500 (EST) Received: from mailscan-1.sys.kth.se (mailscan-1.sys.kth.se [130.237.32.91]) by smtp-2.sys.kth.se (Postfix) with ESMTP id 08A4914EA06 for ; Fri, 25 Nov 2011 00:15:04 +0100 (CET) X-Virus-Scanned: by amavisd-new at kth.se Received: from smtp-2.sys.kth.se ([130.237.32.160]) by mailscan-1.sys.kth.se (mailscan-1.sys.kth.se [130.237.32.91]) (amavisd-new, port 10024) with LMTP id p7r5naBUl4Mn for ; Fri, 25 Nov 2011 00:15:03 +0100 (CET) X-KTH-Auth: kristaps [83.250.6.251] X-KTH-mail-from: kristaps@bsd.lv X-KTH-rcpt-to: discuss@mdocml.bsd.lv Received: from macky.local (c83-250-6-251.bredband.comhem.se [83.250.6.251]) by smtp-2.sys.kth.se (Postfix) with ESMTP id CC0D314C12F for ; Fri, 25 Nov 2011 00:15:00 +0100 (CET) Message-ID: <4ECECFF4.8050000@bsd.lv> Date: Fri, 25 Nov 2011 00:15:00 +0100 From: Kristaps Dzonsons User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 X-Mailinglist: mdocml-discuss Reply-To: discuss@mdocml.bsd.lv MIME-Version: 1.0 To: discuss@mdocml.bsd.lv Subject: Re: man.cgi in "online" mode References: <4ECEB84A.20203@bsd.lv> <20111124223550.GA9283@iris.usta.de> In-Reply-To: <20111124223550.GA9283@iris.usta.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit > Yes, and we'll have to resync, i hope to do a bit of that this weekend, > let's see how far i can get. Ingo, Keep me posted. I've made some changes here and there, but directory-diff'ing between OpenBSD's and mdocml's doesn't cause too many issues. Your nice ignore-certain-files bits are still unmerged (I'd noted on tech@) and I don't see much beyond that. >> What's not mentioned much is man.cgi, which is similar to existing >> man.cgi scripts but with the power of our apropos(1) and mandoc(1) >> as a renderer. > > The biggest problem with that currently is that the interface > is incompatible. Yes, the old interface is horrible (sektion=, > anyone?), but we can't break existing links. I hope to work on > that at one point, but one thing at a time, i first have to get > mandocdb(8) and apropos(1) ready for production in base. > Probably, in some way or another, man.cgi will have to support > both the traditional man.cgi syntax and the new apropos(1) syntax. > I haven't thought about the details yet. Compat isn't difficult -- I've designed man.cgi with an eye for this support (ok, I didn't, but it naturally grew that way). The only headache part is the old manuals, but let's talk about that later. >> To date, I've designed man.cgi to run in "secure" and "insecure" >> mode. > > In general, secure and insecure mode tend to make very little > sense. You want to have one mode that's secure *and* works, > not two (one securely non-working and one working insecurely). > >> "Insecure" mode is for non-jailed CGI processes, scanning the >> system's mandocdb(8) (like apropos(1)) and formatting output with >> mandoc(1). The "secure" mode uses mandocdb(8) databases and a cache >> of pre-formatted manpages, both kept fresh with the new-born >> manup(8) utility. > > The so-called secure mode makes more sense to me, also regarding > efficiency. > > If we need to serve from source code, which i'm not yet sure we > really have to, but maybe i'm missing something, then i'd probably > try to just link both the parsers and the -Thtml formatter right > into the man.cgi executable. Not sure whether that would fly, but > it might be worth a try. > Of course, it's not urgent. First, what matters is a system > that serves the manuals at all, with the right interface. This (linking man.cgi with the mandoc(1) frontends) was my first thought, and in thinking about it twice, may prove the winner in the end. I opted for fork/exec because it took fewer keystrokes at the time. But manup(8) (or whatever the name) can be trivially fitted to copy in manual sources, at which point both "modes" would do the same thing. Yes, I like it. In fact, I think I'll slather some elbow-grease over this idea and see what comes of it. > I tend to think that the so-called secure mode is sufficient > and running one command for setup seems acceptable (i don't like > the name "manup", but that's not a crucial point). Ultimately, > i think giving a working, compatible system and setup instruction > to Bob Beck and seeing what happens will be the test to see whether > what we built is usable, and only when that has run for some time > in public and -current snapshots have been sucessfully installed > for a few times (without Bob complaining about having to do tedious > work) should we consider the design finished and proven good. > Until then, we should be ready to implement tweaks that practice > might teach us. I agree. Again, the "old versions" bothers me, but I don't really have any idea how that's maintained even now. I'm guessing the man.cgi server has a forest of manpage trees in there somewhere. Ugh. >> My thought is to write a Firefox add-in to do this instead, > > I think this has nothing to do with browsers at all, and > writing Firefox plugins is a complete waste of time no matter > what the purpose might be. Perhaps, although I really like the idea of a no-server, browser-based interface. But just using Firefox is painful enough: writing a plugin for it might damage me forever! Think of the wee manuals! Take care, Kristaps -- To unsubscribe send an email to discuss+unsubscribe@mdocml.bsd.lv