On Wed, 29 Apr 2009 16:55:26 +0100, wrote:
> i've done quite a lot with JS embedding in non-browser contexts, eg a JS
> SQLite3 wrapper:
>
> http://code.google.com/p/v8-juice/wiki/PluginSQLite
>
> and might be able to be of assistance here. Another interesting project
> in
> this area is:
>
> ht
On Wed, 29 Apr 2009 21:37:53 +0100, Stephan Beal wrote:
>
> Once one is used to SpiderMonkey, the basic stuff is not at all
> difficult to do (though i will never understand their (undocumented)
> threading API). However... being able to extend fossil via JS is,
> however, arguably of little use s
I operate in an environment without CGI support (We run an Nginx web server,
which
doesn't support CGI). Implementing Fossil using a bunch of it's own servers
behind
Nginx as a proxy is undesirable for a multitude of reasons: It means
configuring a
Fossil service for every repository, which mea
We are currently experimenting with setting up a Fossil server, but have
encountered a bit of an issue: Fossil doesn't seem to support being operated
behind a proxy. As we wish to run Fossil on port 80, and to do so it must
sit behind our primary web server, this is a bit of an issue.
The ideal so
On 30 May 2010 00:53, Michael McDaniel wrote:
> I wound up running lighttpd for the sole purpose of serving fossil
> via cgi scripts. lighttpd is pretty lightweight on resources.
>
> ~Michael
>
The idea has crossed my mind, but the idea of having to maintain another set
of configuration files
On 30 May 2010 02:59, Richard Hipp wrote:
>
> "CGI ... is highly inefficient". The http://www.sqlite.org/ and
> http://www.fossil-scm.org/ websites are both run off of the same server
> (check the IP addresses on the domains). The HTTP server there is a simple
> home-brew job implemented as a si
I've finished modifying Fossil to support SCGI. Some notes:
- I rewrote the accept loop of the server/ui command at the same time. It
no longer uses select with a timeout in order to reap child processes;
instead, a signal handler is installed for SIGCHLD in order to reap them and
main
On 31 May 2010 07:49, Paul Ruizendaal wrote:
> Hi folks,
>
> Two remarks:
>
> 1. I'm happy that more and more people are contributing to Fossil, but I'm
> also a bit concerned about the increasing Posix dependence. The https code
> builds in a dependence on libssl, and now the below patch is Posi
For those so interested, the modification is now being self hosted. See
http://fossil.e43.eu/fossil/. Anonymous cloning is allowed.
- Owen.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/li
On 31 May 2010 15:01, Paul Ruizendaal wrote:
>
> >> I'm really short on time right now, but I will try to help you in
> making
> >> this a cross-platform patch. I can test on WinXP, Linux and FreeBSD.
> Can
> >> you test on OS-X?
> >
> > No, sorry. I can add OpenSolaris to the testing platforms t
SCGI is so simple that its pretty much impossible to implement wrongly.
The only brokenness that I've seen is that nginx' SCGI handler (Which is a
somewhat unmaintained 3rd party module) doesn't accept status: lines like
its supposed to. The work around took one line, however. If I ever get
around
On 2 June 2010 18:11, Joshua Paine wrote:
> Only 127.0.0.1 is privileged, right? So can we just not trust
> X-Forwarded-For: 127.0.0.1 no matter who says it, and not worry if
> X-Forwarded-For is abused otherwise?
>
No. Fossil keys its login cookies off the user's IP address. If the user
can pr
On 25 June 2010 11:15, Sergey Sfeli wrote:
>
> Ruslan Popov wrote:
>
> > I've tried to use Fossil on russian version of Windows 7. I made commit with
> > russian text in comment, when I run the UI and look at timeline, I saw that
> > russian text looks like squares.
>
> Why don't just use text edi
The trouble is that UTF-8 is a poor standard. It bloats many texts, is
quite expensive to parse, and has only one redeeming feature: It never
creates embedded nulls. I suppose that it shares its encoding with
ASCII is a feature too, but only a minor one.
Personally, I think that most systems shoul
One of the reasons that I'm a fan of SCSU is that, with even a
relatively simple encoder, it produces output which is comparable in
efficiency to that of most legacy encodings.
On 25 June 2010 18:53, Michal Suchanek wrote:
> On 25 June 2010 18:09, Owen Shepherd wrote:
>> The troub
On 25 June 2010 19:36, Michal Suchanek wrote:
> On 25 June 2010 20:18, Owen Shepherd wrote:
>> One of the reasons that I'm a fan of SCSU is that, with even a
>> relatively simple encoder, it produces output which is comparable in
>> efficiency to that of most legac
On 26 June 2010 13:47, Michal Suchanek wrote:
> On 25 June 2010 21:37, Owen Shepherd wrote:
>> On 25 June 2010 19:36, Michal Suchanek wrote:
>>> On 25 June 2010 20:18, Owen Shepherd wrote:
>>>> One of the reasons that I'm a fan of SCSU is that, with even a
On 26 June 2010 20:59, Michal Suchanek wrote:
> Indeed, the loss is at the end in case of web pages, parts which are
> missing in the middle are result of inserting different streams so
> SCSU would not suffer more breakage than other encodings. Still there
> is no apparent benefit in using it.
F
On 8 Sep 2010, at 18:32, Richard Hipp wrote:
> A key point is that the sync mechanism does not know anything about the
> meta-information or the internal format of the artifacts. All sync knows is
> that there is some set of artifacts on one side of the connection, and
> another set of artifa
19 matches
Mail list logo
