Developers, add your list of things you want to get into Foswiki 2.0 below. This is not a wish list of things other people should do. It's a statement of what you realistically think you can do.

CrawfordCurrie

• A database-based search solution. This doesn't mean changing the core to use a database; it means keeping the RCS store but cleaning up the core interfaces such that two styles of database usage are possible:
  1. Caching topic data so that database ops can be used to search. Existing things that work this way (or can benefit) are:
     • DBIStoreContrib
     • KinoSearchContrib
  2. A full database-store implementation, e.g. FavioFlamingo's work on DBIStoreContrib, replacing RCS with another store technology. Must fully support efficient searching in the back-end store.
     • MongoDBPlugin - SvenDowideit - I'm only working on the hard part first - getting foswiki abstracted enough and making Search super scalable.
• Full implementations of order and groupby sorting of search results.
• Pluggable JS validators for form data input i.e. when you input a value in a Foswiki form, you should get immediate feedback, based on a validator selected from the form definition.
  • Synergy with FormPlugin to be explored
  • MD suggests: integrate JQueryPlugin's jquery.validate methods with formfield types

PaulHarvey

• Release EditorAPIPlugin. It is meant to replace TinyMCEPlugin. Implements richtext formfield type, IE. Wyisywg formfields. Allows switching of editors on-the-fly. In a broader sense this thing is structured to define content types (eg. wysiwyg text) which may have various editor implementations (Eg. TinyMCE, raw, preview) and these editor implementations must hook in to a javascript event handler which manages the editors (switch, save, cancel, etc). The abstraction may not be generally useful; probably thrown away if we ever get around to re-designing Foswiki::Forms. The use-cases in mind revolve around various Foswiki::Form::Foo field types, rather than anything more ambitious.
• Push QueryAcrossTopicRevisions

SvenDowideit

• Get MongoDBStore working as the fastest and most scalable store it can be - at this point, we're assuming it will be faster and more scalable than a DB store using the same HW.
  • topics stored in MongoDB Collections
  • Attachments stored in MongoDB's GridFS
  • sessions and logs in mongo..
• Push GrandUnifiedSearchAPITwoZero
  • QueryAcrossTopicRevisions
  • AddExtraSetupToUnitTests

and then there's a bunch of deferred features and tasks.

ArthurClemens

• Create a BaseSkin as lean fundament for other skins
  • Use SASS to manage css
  • Use AJAX for a more streamlined UX, see RethinkingTopicInteraction below
  • Rethink UI of current templates
• New topic interaction
  • Inpage editing
  • Topic interaction navigation
• Turn groups into collaboration units

---

Discussion

I'd like to note that we have a strong desire from the developers to goto 6 month release cycles, which means that the above list should be what the developer thinks they can have completed by mid-Febuary so that we have some chance of releasing.

Additionally, I think its a bit weird to have things listed here that are not FeatureRequests..

• Some things above will encompass many feature requests and tasks - it's a 10,000m view

-- SvenDowideit - 16 Oct 2010

I agree that it's a bit weird with this new topic. We have a ReleasePlan topic. I've tried to update it to be search based against Feature Requests. It would probably be better to stick with the FeatureRequest and ReleasePlan topics and allow this topic to die. Development.ReleasePlan#Release_1_2_may_be_rolled_into_2 The FeatureRequest topics are in pretty bad shape and need to be cleaned up rather than starting a new topic like this one.

(And it looks like anchors are broken on trunk. The anchor link to ReleasePlan doesn't work on trunk, works fine on 1.0.9). Trunk and 1.1 encode all chars in a heading, not just word chars now :/ - PH

-- GeorgeClark - 04 Jan 2011