Warning: session_start() [function.session-start]: open(/tmp/sess_02e0f9c636146372af3b1d929001ecac, O_RDWR) failed: No space left on device (28) in /var/www/wiki/htdocs/inc/common.php on line 10
Warning: session_start() [function.session-start]: Cannot send session cookie - headers already sent by (output started at /var/www/wiki/htdocs/inc/common.php:10) in /var/www/wiki/htdocs/inc/common.php on line 10
Warning: session_start() [function.session-start]: Cannot send session cache limiter - headers already sent (output started at /var/www/wiki/htdocs/inc/common.php:10) in /var/www/wiki/htdocs/inc/common.php on line 10
Warning: Cannot modify header information - headers already sent by (output started at /var/www/wiki/htdocs/inc/common.php:10) in /var/www/wiki/htdocs/doku.php on line 33 jaws:development:roadmaps [Jaws Project Wiki]
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, docs.jaws-project.com)
Write a security gadget that manages security stuff in Jaws, like XSS parsing level (paranoid | normal), block users via IP.
Use the captchas.net services instead of our crappy Captchas stuff. Advantages: it’s already tested in captchas.net, 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