Our project fork hit the one year milestone a week or so ago, and Arthur noticed this amazing ‘factoid’ on ohloh..
Very large, active development team
Over the past twelve months, 36 developers contributed new code to Foswiki.
This is one of the largest open-source teams in the world, and is in the top 2% of all project teams on Ohloh.
For this measurement, Ohloh considered only recent changes to the code. Over the entire history of the project, 43 developers have contributed.
All I can say, is WOW and thank you, to everyone that has worked on our project, and to all who discover it.
The Foswiki Association & Summit is happening in Hannover at the end of this month – I wish I could be there, but its a long way from Australia – maybe next year 🙂
I’ve updated the USB Foswiki to include foswiki 1.0.7, and updated the systray controller to be a little more slick 🙂
I’m still looking for feedback from users – Its a nice fast way to try out foswiki without needing to install anything – just unzip the archive into the root of a disk, and click start_foswiki.bat (on Windows XP the autorun should start that automatically for you)
I was asked on Friday night if I could make a demo foswiki USB system, and given that its high time we did one, I started to look into it. Initially I thought this would be a great oportunity to try out the HTTPEngine work Gilmar has been doing, but we’re not quite there yet. And so, I started a quick perusal of the existing WebServer on a Stick systems. Ideally, I want to use Strawberry perl, apache, and have the server and a browser start up automatically when the USB stick is inserted into the computer.
MicroApache
Server2Go
XAMPP
MicroApache was the first thing i looked at, as the contact pointed out DokuWikiOnAStick, but that server doesn’t seem to have source, nor is the upstream web site there (last release seems to be 2007, so too old for Strawberry perl too) Server2Go looks nice, but as its not really free in the debian sense, I’ll pass on that unless nothing else works. XAMPP – unzipped it, foswiki and did some minor configurations. unziped, removed everything except apache, added strawberry perl, and wrote a systray icon and menu system for you to control it with. TADA! FoswikiOnAStick v0.1v0.3 (running foswiki 1.0.6). please try it out.
unzip it to the root of your USB key (or any drive)
start the systray app, web server and browser using start_foswiki.bat (goto http://localhost/ if the browser doesn’t start) (unblock / allow apache to get through the windows firewall)
before ejecting the usb key, you need to stop the webserver by running stop_foswiki.bat yes, thats all. Please report any issues or observations to me – SvenDowideit@fosiki.com
the web server runs at the standard port 80, so if there is already a web server running it will fail
when the web server starts, it will probably be blocked by Windows firewall – every time I’ve tested, a dialog pops up, and allows you to unblock it.
….
Warning
I have made no attempt (yet) to reduce the accesses to the disk – so it may use up all the blue smoke in your usbkey, cause your bits to turn green, or one of many other unforseen side effects which may or may not appear amusing if they happen to someone else. I’ve tested this on Windows7rc, Windows Vista, Windows2003server, and Windows XP – if it works for you, excellent :).
Now we have 2 possible icon sets to replace the very odd and aging DocumentGraphics topic – the only thing holding us back is a mapping from the old %ICON{}% names to new.
I’ll dig up the work I did last year some time and see if we can finish it 🙂
I was just asked on IRC how to protect some attachments without forcing all requested attachments to go through the viewfile cgi script (as that causes your foswiki images and css to load incredibly slowly), and here’s the howto I answered with:
I was just asked on IRC how to protect some attachments without forcing all requested attachments to go through the viewfile cgi script (as that causes your foswiki images and css to load incredibly slowly), and here’s the howto I answered with:
I coded foswiki 1.0’s viewfile script to work as an apache ErrorDocument, so If you can find a way to trigger a 404 or 401 error, you can get apache to run viewfile –
If you place your pub dir somewhere outside where apache serves files and then softlink the non-protected webs into apache’s path (so it serves them full speed), then the secured webs will generate a 404, triggering the viewfile ErrorDocument – which will thus serve the file only to authenticated users
This will work irrespective of the authentication choices in your foswiki setup – and as the files that require securing are outside apache’s file serving areas, can be considered as secure as possible.
As an added bonus, any request to a file that does not exist will show a foswiki error page, rather than a static html.
