Re: [fossil-users] Fossil CGI problem

2011-01-17 Thread Kulcsár Ferenc

 Any reason for not using one of the established web servers that
 actually implement the specs correctly? E.g. with nginx you can either
 hook up fossil http via inetd or directly proxying fossil server.

If I understand it correctly fossil uses non-parsed headers in its answers
(runs as a non-pased header script). In the CGI 1.1 specification you can
find this:

5
5.1
NPH Scripts
Identification
The server MAY support NPH (Non-Parsed Header) scripts; these are scripts
to which the server passes all responsibility for response processing.

Bauk didn't imlpement it - if I got that right - but that's right because
the specs are implemented correctly.

I like Bauk and its features and won't install other servers/applications.

Regards,
Feri

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users


Re: [fossil-users] Fossil CGI problem

2011-01-17 Thread Richard Hipp
2011/1/17 Kulcsár Ferenc crusa...@netbsd.hu


 If I understand it correctly fossil uses non-parsed headers in its answers
 (runs as a non-pased header script).


I don't think so.  The webserver on the http://www.fossil-scm.org/ website
does not support non-parsed headers but it supports Fossil just fine.

I suppose the previous sentence depends on your definition of non-parsed
headers.  The webserver at http://www.fossil-scm.org/ certainly does look
at and parse the result it receives from CGI prior to relaying it back to
the requester.



-- 
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users


Re: [fossil-users] Fossil CGI problem

2011-01-17 Thread Joerg Sonnenberger
On Mon, Jan 17, 2011 at 09:32:22AM +0100, Kulcsár Ferenc wrote:
 
  Any reason for not using one of the established web servers that
  actually implement the specs correctly? E.g. with nginx you can either
  hook up fossil http via inetd or directly proxying fossil server.
 
 If I understand it correctly fossil uses non-parsed headers in its answers
 (runs as a non-pased header script). In the CGI 1.1 specification you can
 find this:

No. Fossil depends on the server implementing 6.3 of RFC 3875
faithfully. Bauk adds a header that the CGI doesn't support (which is
bogus for POST requests) and it drops a header that the CGI created
(content-length). The latter is actually a big no-no for any web server.

Joerg
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users


Re: [fossil-users] Automatic creation of file to wiki or embedded docs

2011-01-17 Thread David Bovill
On 17 January 2011 01:29, Ron Wilson ronw.m...@gmail.com wrote:

 On Sun, Jan 16, 2011 at 5:24 AM, David Bovill da...@architex.tv wrote:
 
 Do you mean only in Fossil's file display,


Yes - this is the main need. Simply put you have to be able to move back and
forth between source code and documentation.


 or are you looking for a
 way to automatically have a link in the source file's header back to a
 wiki page?


No - I've used that before with svn - but it's a minor issue and tends to
complicate things.


 Another thought that occurs to me is that source code could be
 embedded in .wiki files using the code or verbatim tags. A rule in
 your makefile or build script would define how to extract the source
 from a .wiki file. For example, a make rule for C++ source would be:


Embedding source code in the documentation is useful - it's the sort of
thing you do on Trac or other full blown wiki systems. But I think this
would be a lot of work, and there is always something else that would be
useful to embed etc (which is why Trac etc use plugins).

I'm trying to keep it simple - so going back and forth between tow pages is
fine for now. It's not fine from a UX point of view, to have users need to
use the browser back button.


 .wiki.cpp:
  sed -n -e '\#code#,\#/code# p' $? | sed -e '\#/?code# d' $@

 This would allow extensive documentation, as well as wiki markup, to
 be interleaved with the code.


True but I think it is prob a lot more work - than adding a simple link to
the file info page, or better opening up / describing how to hack the
template for pages like this?
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users


Re: [fossil-users] Automatic creation of file to wiki or embedded docs

2011-01-17 Thread Rene
 On Sun, 16 Jan 2011 10:24:16 +, David Bovill wrote:
 One think I'm missing in terms of usability is the ability to
 intimately link a particular source code file with a wiki page. AFAIK
 this is not part of the structure or interface at the moment - so no
 wiki-tags for linking to / embedding the source code from the wiki.

 as said before you can do that with an [url|display] to the file of you 
 desire.


 It seems that this may be partly possible by creating your own custom
 header in the wiki page - but there is no equivalent for the file
 display page? basically I want to have two-way links between the
 source code file and  a root documentation page. Probably using the
 Embedded docs as then the docs and source code are versioned 
 together.
 You can link to the source code file. But the source code file cannot 
 link to the
 documentation. As said before there is no wiki parsing for source code.


 Is there a way to access / alter the html template for the non-wiki
 pages? In general it is nice to have these templates in the wiki
 itself - reuses the code and allow total flexibility in terms of
 customisation? But if these files are stored in the db somewhere I 
 can
 access and alter these directly?
 All the templates fossil is using are under Admin (header, footer, 
 [skins, css])
 and you can change them as much as you want.

 But the template language is basic, no include other templates. TH1 
 is available so
 you have if then else. But you have to code everything in the header 
 and the footer.
 for instance if you detect that the page is version.c then you could 
 generate a link to the documentation.
 But al the intelligence for connecting the source code to the 
 documentation must be contained in header and footer.

-- 
 Rene
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users