Table of Contents



  • Cache Registry|ACL Keys on a file and only load it when the gadget is called. Only *core* stuff and basic information of gadgets (like /enabled, /version) will be stored in DB.
  • New SOAP and XML-RPC interfaces, PEAR::SOAP and PEAR::XML_RPC until we go to PHP 5.1+ only … Probably XML_RPC2 on 5.1+ and the native SOAP thing
  • SQLite and OCI8 support, maybe ibase. SQLite seems to work fine, needs more testing tho, this mostly means, try Jaws on those databases and see what we have to change in our MDB2 interaction and even help fix up MDB2 to support them better.
  • Implement more events, like making jaws trigger all those events we have in the database when those things happen. We might need to refactor this about, we’ll see.
  • TinyFCK instead of TinyMCE as editor (gives us a nice upload UI crap, we have to hack that around also), it’s basically TinyMCE with the FCK upload JS interface on top of it.
  • Chatbox, when viewing on the admin side, only show half of the info we show now and when clicked then it untoggles the rest … below ..
  • Fading messages … have some time limit … not too short, don’t fade out error messages or warnings. Reason: We want people to actually being able to read those message and also fading error and warnings is a bit pointless if we want people to be able to reference those error messages while they are fixing what ever the problem is.
  • JawsRequest used and improved
  • Way to have the VisitCounter gadget on the site with out showing an output as such i.e. count visitors but no grapihcal counter visable to users.
  • Better DataGrid support, AJAX sorting of tables, pagenation and such. This could mean we’d either have to keep our own version in Jaws or extend the Piwi one, mainly because of database interaction part. Reason: It can be fubar to have like 40+ entries on the same page, so we need pagenation ( 1 | 2 | 3 | 4 stuff) and to be able to sort those we’d have to have AJAX sorting … The smartest thing to do is if we could only load the AJAX sorting when the items need more than 1 page, for load purposes.
  • Standardized loading ajax thing on things that need it, find a special place for it, similar to Gmail loading. Reason: Consistency is a very powerful thing, gets users used to looking at only one place to know if things are still loading or not.
  • Docs, API and end user docs (as in bring them up2date and write new ones, tutorials and tips&tricks and such,
  • Auto-save drafts like in Implement this stuff in the editors so when fooEditor is called a Javascript will be created to handle this task.
  • Show a Javascript confirmation (alert) when trying to exit from modifying some info without saving, like this wiki “There are unsaved changes that will be lost. Really continue? [Yes] [Cancel]”
  • Write a security gadget that manages security stuff in Jaws, like XSS parsing level (paranoid | normal), block users via IP.
  • Use the services instead of our crappy Captchas stuff. Advantages: it’s already tested in, fonts are a bit more clear (and bigger), and have phonetic support.
  • Write a subscription gadget where users can register their emails and select a list of stuff they would like to get information. Jaws administrator can decide what to offer to users, like blog updates, phoo updates, etc. The way to implement the subscription gadget is via Event Listeners (onUpdatePost ⇒ sendSubscription, onUpdatePhoo, send Subscription, etc..). Jaws admin can also decide when to send the subscriptions (for example on every 10 new items).


  • Basic XUL frontend
  • Basic SOAP support for more things. (where sensable of course)
  • Change over to PEAR::HTML_AJAX. Reason: It’s maintained, JSPan is kind of dead I guess and we can fool David C (hopefully) into helping us maintain that part ;). More information here
  • Piwi should support server side validation (so that we can have either JS or server side, or ever both)
  • Validate urls with PEAR::Validate::uri and emails with PEAR::Validate::email
  • ControlPanel + Themes (discussion has to happen as to how to implement this properly)
  • Support for different gadgets as ControlPanel (we already have a registry entry that has the current controlpanel name in)


  • Phoo export to Flicker
  • Import from Gnome / KDE to Phoo some how, also some integration into f-spot ?
  • Better integration of Blog and Phoo in regards of storing images for blog posts, another idea would be to make a image storing gadget that’s independant on phoo and blog and those 2 just use that new gadget.


  • Introduce REST, There’s already support for this, we just need more support + testing + fix/improve everything that comes out of that testings
  /var/www/wiki/htdocs/data/jaws/development/roadmaps.txt · Last modified: 2007/11/02 16:27