- before writing the full ticketing system:
xx Index.<field> to the scaffold HDFs by walking db_index
--- add a /*^* hasmany=field:type[:del]; */
----- should be easy to add a list of has_manys and belongs_to to the evapp_db
----- can then just map them straight into the hdf like with Index
------ once done, abstract out the code so any app can do it.
---- this will allow automatic scaffolding and remote data inclusion via JS :-)
--- make the sorting / secondary indexing make sense
---- change by --> only
---- add 'by' to be sorting priority only

-- add use of evhttp_start_reply/etc so that chunked responses are used.
-- move over all access-heavy data structs to heaps: request_router, etc
--- alternately, use bdb and open in-memory dbs.
---- could even place all indices and other stuff in for quick ref.

-- add db interfaces for direct evrpc objects and make the _hdf functions use them
--- use this to write a list function wih a callback so that we can do chunked responses of arbitrary length without blocking
-- consider adding a "write" thread which picks up write-jobs off a queue and avoids blocking the main thread.
--- writer does a cond_wait(). when a reader adds a job, it wakes it
--- jobs are stored on a shared tailq (FIFO) with a write mutex
---- assume no status is returned.
----- Could be supplied via a db update:
------ write job is added and a unique transaction id is generated
------ when the writer does the job, it also creates the transaction record

-- add logging support directly to the database
--- evapp_log(ctx, fmt, ...); --> write to db except when not daemonized
-- write log dump tool ("".decode("hex") :-)
-- leave out auth since users are not a core concept (yet)
-- add listby strings! -maybe a query arg
-- add query arguments to list and listby
-- seriously clean up the code :-)

-- add support for a "bytes" type

-- see if it make sense to store the "type" of indexed fields as an enum instead of a char *
--- this would mean coding the enum in the code generator as well. blah.
---- could have a function that maps a string. then it could check.
----- it would move all the work to the startup and off the serving.

-- WRITE SOME DEVELOPER DOCS :-)

!! figure out how to ensure writes are being written back to the log at the very least!!

- other todo items:
-- later consider adding support to use mysql where the schema just matches the rpc file
-- add multi-platform support
-- consider gzip support for responses
-- add default 'validate' function which checks that all foo_id exist in their requisite tables. (crawl hdf, then do a db select and add db-exists)
--- this wont due when ti comes time to cross-link data that may have access controls...
--- actually it wiil if we implement the has_many and belongs_to meta-logic
---- consider adding users and data object access controls as a core feature
-- add support for read-only mode to allow multiple readers with no chance of a deadlock
- add comprehensive NEOERR handling (e.g. all thos hdf_inits).
-- this will avoid memory leaks on errors
- add internationalization support to the template loader and handlers
-- e.g. make template database per language and then load from them?
--- use the internalizatin support in CS to "pre-generate" each language.
-- write my own safe escaping functions
---- including a JSON escaper (.. -> u'XXXX')
-- make sure any JSON isn't script src-able (post helps..)
-- look into using mtemplate (pretty stuck with CS for now though)
--- it'd be nice to write a parser for event_rpcgen's spec for mtemplate and remove the additional code generation
-- figure out how to handle file upload?
-- add signal handler for HUP to checkpoint the db
-- add signal handler for TERM, INT to shutdown cleanly.
--- add "shutting down" response to request_router
-- replace lots of uri parsing code with macros.




---- web app specific stuff here


- how to do auth?
-- how to use generic functions but add auth, etc.
--- maybe add a generic auth layer easily pulled from the hdf?
--- maybe add a auth objects - those dont have to be generic.
---- checkpoint before doing that.
- add authentication filters
- add authentication mechanism!

- actually start implementing the real webapp