The biggest thing I expected to find missing â and was surprised to find
that it is not â is gzip compression on the HTTP layer. That alone will
help tremendously with multi-MB pages. I wonder if the person reporting
that is counting the on-the-wire size or the uncompressed size.
It should be compressing, at least based on what i see in cgi.c. The
CGI-mode output APIs buffer up the content/body, and compress it as a final
PageSpeed reports that Fossil isnât minifying the skin CSS. Little
wonder, since it offers an inline editor for the raw CSS. Nevertheless, it
would be good if Fossil created a minified shadow copy of it and served
Interesting idea. i don't know if we have enough CSS to make this worth the
YSlow gives a confusing report about favicon.ico not having an Expires
header, but what it really means is that Fossil doesnât provide a
favicon.ico, so the browser wastes time trying to fetch it on every page
load. If Fossil were to serve such a file along with a far-future Expires
header, it would prevent the browser from repeatedly trying, speeding page
loads. (Yes, you must serve more content to make things faster. Welcome
to the modern Internet.) It should be part of the skinning mechanism, of
Consider a favico added to the TODO list. Can't believe that never came up
Other than that, Fossilâs generated tree-view HTML looks pretty good to
me. (I speak as a professional web app developer.)
It has little unnecessary whitespace
The reason for that is because it's created via C strings, where
indention/formatting of the HTML isn't all that useful.
, and I found no inline styling; Fossil is delegating all styling to CSS,
as far as I can see.
A few years ago you might have. It's nice to hear we haven't got any left.
The only thing that could be a bit better is that the inline JS could be
minified, but that is notoriously difficult to do in an automated fashion.
Iâve used JSMin and YUI Compressor for this in my own web apps; it is not
something you want to try and roll by hand.
The JS is also in C code. Normally someone develops it in a local JS file
or their browser console, then paste it into C and adds quotes around it.
It's baked into the binary, so minifying would have to be done on the fly
and would have little benefit because we have little JS.
âŠsays he to the one who rolled his own RDBMS, parser generator, and DVCS.
... binary-capable diff algo, single-function hashtable interface, ...
i'm continually amazed by little snippets by Richard which i know would
take me 10x as much work to implement. "Oh, hey, we need a little binary
Annnnyway, if you do add JS minification to Fossil, it should be part of
the build process for Fossil, rather than something it does on the fly.
it can't be done with the current code b/c the JS is baked in. We (well, HE
;) recently added a mechanism for importing such resources from files, and
we "could" minify any resources stored in that mechanism.
JSMin has a very âFossilâ sort of feel to it: single C source file, with
no external dependencies other than a C compiler. It doesnât even ship
with a Makefile! Itâs under a BSDish license, so it could be put into the
Fossil source tree and used during the build process.
already got it in a couple of trees :)
Also, JSMin would occasionally do the wrong thing with certain very
large 3rd party JS libraries, particularly when concatenated with *other*
very large 3rd party JS libraries, in order to reduce the number of HTTP
round trips. Fossil doesnât have either of these problems.
Nope - we've got a few snippets of hand-rolled stuff, but so far no notable
3rd-party libs (except maybe the wysiwyg editor).
Besides that, YUI Compressor isnât suited to the nature of Fossil: it
ships as a ÂŸ MB JAR file.
"I told him I needed help opening a jar. He said to install Java."
(It makes more sense in the context of the picture it was written on.)
----- stephan beal
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf