Nuts And Bolts

Headline

Foswiki has a range of nuts and bolts that fits most use cases. Documentation provides an introduction to developers and users alike to create a wiki environment, however, it is not sufficient to tell the world what are all the real world possibilities.

Foswiki need an area that able to showcase the nifty things that Foswiki can offer. It is strictly simple tweaks that can be done with a minimum of one line or more. Essentially, it's a know-how tutorial.

This area is not to showcase what the extensions is for, but what the built-in features and extensions can do when fused together.

Guidelines

1. Provide comprehensive study of the Foswiki tweak, i.e. must include step by step guide
2. Authorship must be retained. Contributors are acknowledged.
3. Any sizeable tweaks will be re-packaged as a Foswiki extension.
   • How do we determine this?

Examples

1. Autocomplete parent topic in NatEdit
2. Gmail on Foswiki
3. How to create a glossary

Proposed area

1. Runs the latest releases of Foswiki and its extensions
   • Provides consistency to what end-users/developers would expect
2. Installs all Foswiki extensions
   • There are extensions that are in conflicts
     • Tasks.Item1144
     • Tasks.Item1145
     • ...
   • Loading too many would cause a huge performance hit - maximum of 20 extensions?
     • How would we determine which 20 extensions? What if others wants to install an extension? What's the policy in adding a new extension?

Discussion

Standalone setup

1. This setup is detached from the main Foswiki website.
   • a navigation link from Documentation, Support, About, or Extensions
2. Able to work solely in UTF-8 Questionable?
3. Provide all users with total control, except configure and System Web
4. User profiles must not be copied over from the main site due to potential security risks if this setup is compromised.

Advantages

1. One-stop-shop in understanding Foswiki.
2. Provides a fully comprehensive and workable area for end-users/developers.
3. Complete collaboration from anyone with hands-on approach.
4. Able to spot quickly on extension conflicts.
5. allows the showcase maintainers to ensure the best possible setup for that showcase - they know best what is needed
6. reduces the risks of bringing down our main site.

Disadvantages

1. Maintenance from the InfrastructureTaskTeam
2. Require an additional machine/virtual-machine
3. ...

A subweb of Foswiki site

1. As part of the main website as a subweb
   • under Documentation, Support, About, or Extensions
2. ...

Advantages

1. Central and easy to maintain

Disadvantages

1. Maintenance from the InfrastructureTaskTeam
2. Performance hit from loading all extensions!
3. Additional mess to the main website.
4. Raised risk that a showcase causes issues for the main site - plugins, security, simply DOS-ing.

Discussion

---

Quite honestly, the InfrastructureTaskTeam would likely have a workload from either approach, but if we can develop a sandboxed approach, any one showcase can be terminally broken, without impacting on our main site - which is rather important to our day to day working.

There is little reason for the user to be aware that there are seperate servers / vms / installations serving up the main site and the showcases - apache is pretty good for being set up to proxy/rewite/hide the implementation details.

• SvenDowideit - 10 Apr 2009

While I still think linking this examples/demos from the Extensionhub would be good that's not the goal itself. The examples should be very easy to find for someone browsing. Their browsing may come from several angles, from looking at an extension, browsing support, reading the FAQ. Of course there are other technical ways to link demos and support/extension. A sandboxed approach sound safest since some demos could cause unwanted side effects.

-- LarsEik - 10 Apr 2009

We have at two (tm)wiki summits agreed to create an Apps or Applications web and I have volunteered to drive its creation.

Unfortunately the creation always ends up in talks that mix many other purposes into the equation and we never get anywhere.

What I want is a web with a simple web application where people can exchange small simple applications either inside a topic or by attaching topics in a zip file.

I want to create an application community. Not of perl hackers but normal people with no programming skills and no knowledge about Subversion or build contrib.

If we mix this up with large demos, videos, packaged Contribs, and automatic installers, etc we never get anywhere.

What I would prefer is that this is done on the same server that runs foswiki.org but in a different Foswiki installation where we can install the standard PatternSkin and maybe 20 extra plugins so the Applications can demo things with the most popular plugins. Which extensions is not a big deal. We add one more if someone cries to demonstrate it. I have a pretty good idea which extensions I want installed. It is not cache or user mapping extensions we would add. Just the kind of extensions that people use to build applications. E.g. ChartPlugin, and JHotDrawPlugin.

Same Foswiki instance can then also have webs for demoing skins, and complete applications like the ones Sven and I have uploaded as Contribs.

But the Applications Community would require only ONE web. And if we do not want to setup an additional server we can create the Applications community web as a web on foswiki.org - with the extensions we have today.

-- KennethLavrsen - 12 Apr 2009

I have started a little area which I think this Topic and the associated discussion were trying to address - Development.SimpleWikiBuildingBlocks - it was in the Sandbox web but it got moved to DevelopmentDevelopment. Is this the sort of thing you were wanting to show.....??

To expand a bit more, I have reasonable knowledge of Excel and Visual Basic for Applications andam looking to use wiki (either flavour) to replace the plethora of spreadsheets floating round the Pre-Sales organisation so one of the purposes of Development.SimpleWikiBuildingBlocks is to help provide others with that translation and also some simple bits of Javascript to enable some reasonable level of sophistication of the User Interface without relying on too many wiki enhancements as I am not an admin of our wiki so am limited by what Plugins have been loaded.

Sven - thanks for the credit - I am chuffed...

-- NeilGood - 17 Apr 2009

Kenneth - I agree, and imo Neil has done good work (as did others previously) - which is really the only thing that has symied the idea - someone needs to start and continue doing - where it goes down the track is totally irrelevant, and will become obvious as time goes on. It is after all a wiki :).

I do think that the Development.SimpleWikiBuildingBlocks work really should start out in the Support web, and when it becomes too big, move elsewhere..

-- SvenDowideit - 17 Apr 2009

Next NatEditPlugin will have autocompletion for reparenting. Better create a task for it next time together with the patch and assign it to me. Otherwise valuable contributions like this will be lost.

-- MichaelDaum - 20 Apr 2009