HTDB : Docs : Roadmap : URI mappings
About
Overview
Philosophy
Features
News
Download
Help Us!

Docs
Overview
Designers
Developers
Roadmap
Ramblings
URI maps
Architecture

Community
Powered By

[home]
one of the little annoyances with using libhtdb for CGI writing is the whole if/elseif/elseif/.../else mapping of URIs to the actual called routines. for example, we do a lot of the following:

if (htdb_equal("page", "blah.html")) resource = doBlah(); else (htdb_equal("page", "buh.html")) resource = doBuh(); . . .

this method is easy for a newcomer to "get".

but recognize there is a distinct mapping occurring between a URI and a distinct function called - and this mapping is hardcoded.

i'm toying with the idea of moving the URI/function mapping handling into the core of libhtdb. in such a world, all "handler functions" would be some form of a DSO, and there would be an external/configurable .htdb file mapping between URIs and called functions.

in such a world, there would be a single, quite simple CGI whose behavior is to lookup the mapping between a URI and a called function. if no such mapping exists, then it falls back to the simple "static document" lookup employed by the htdb CGI itself.

benefits:

  • runtime start-up would be quicker, as the executable would be tiny.
  • flexible realtime mapping of URIs to handlers.
  • potentially smaller runtime executable, as the size would grow as only the more common handler DSOs are sucked-in. (handleX.o would become handleX.so - no more static linking)
  • the external list of mappings would allow for a definitive "state map" - testing could be somewhat automated.
  • recompile a single DSO instead of a full CGI - realtime bugfixes, er, i mean feature additions, may be less intrusive.

drawbacks:

  • maintaining the external mapping is a manual process
  • to the uninitiated, this method would one step further from procedural programming - it may appear more confusing than a bunch of if/then/elses.

what got me started on this...

i was mulling over that fact that CGIs are simply state machines - if you have the right set of input, you will drop down into a known handler. this led to the notion of the need for a more formal state engine handler - we're basically asking "give me object X", so there should be an easy way to know how to give X instead of following code logic to determine the right handler.

thoughts?

-del
Sun Jan 6 19:49:09 PST 2002

   
11,439 impressions