goldfish is an in-process in ram db. currently persistance is uni-directional if you change goldfish.db the process will only know when it loads the db file into ram.

To support multi-process use (ie: multiple instances that all access the same hdd) we need some kind of messaging mechanism to notify other processes of changes to keep their data in sync.

note: gluster.fs is looking like the solution for syncing the /data folder between servers. although multi-server support is a separate issue. for this assume multiple processes on the same server.

note: we don't want to load the entire db into ram more than once. consider opening a separate issue for only keeping hot data in ram, with a mechanism / index of byte positions for records / cursor functionality.

note: another separate issue or alternate approach is splitting goldfish into it's own server.

Template with:

[[ 
var email = (fin._meta.hashbang.match(/\/([^\/]+)\/[^\/]+$/) || ['',''])[1]
var activation_code = (fin._meta.hashbang.match(/\/[^\/]+\/([^\/]+)$/) || ['',''])[1]
]]

<form id="activateform" ajaxform hashbang="blog/admin/forms" command="activate"
    validator="fin.fn.blog.activateValidator" onSuccess="fin.fn.blog.activateSuccess">

    <label for="email">Email:</label>
    <input name="email" type="text" value="{{ email }}"/>

    <br /><label for="activation_code">Activation Code:</label>
    <input name="activation_code" type="text" value="{{ activation_code }}" />

    <br /><input type="submit" class="btn btn-primary" value="Activate" />
    <br /><a class="btn btn-inverse" href="/#!/blog/admin/login">Login</a>

</form>

hashbang shouldn't be split into an array in handleApi(). instead have consistent splitter for pathname, hashbang, and command that can be used as required in the router method.

add an attribute to ajaxforms to specify the number of simultaneous requests. default to 1. prevent resending the form until below request threshold.

say I save configuration in the database via one instance. other instances do have access to the database, but they don't know the configuration's been updated.

All the server instances should be notified that the value's been updated.

initially just ties into nav() function hooks to track 'page' views to google analytics.

• fin should generate a unique key on load. two tabs would have different keys
• tail uses the key to keep a micro-representation of the data that's been sent to that client.
• the key will automatically expire on tail in x-minutes. fin will send a heartbeat
• tail can check when a record was changed, when it was sent to that client, and whether it needs to resend it.
• note: we can extend this to store client'd data model locally, client can generate micro-representation of data it has, and send it to server to re-establish the cache session if tail has cleaned it up.

co-ordinate with guppy,fishtank, aquatic, jellyfish to gracefully relaunch node app or exec on error.

existing connections should be allowed to be handled by the dying process, or passed onto the new process. new connections should only reach the new process

Create preferably in-process or otherwise very lightweight db

• target audience are fishtank users, rapid prototyping, simple apps that don't need to scale but still need querying capabilities.
  • "It's not worth it for user to consider configuring, running, and allocating resources/deploy efforts for a database, it's also not worth user having to deal with migrations."
  • "user's entire database will easily fit in ram. say ~100 blog posts. user just wants to be able to query and persist data"
• preferably can scale to aquatic platform in some way
• expand on fin's data structure, dotkeys, fin() dot notation bdd style object querying, to support indexes. consider query language parsing
  • fin already expects an _id based data object with dotkeys
• persists to /data folder.
• needs to support multiple processes changing the same file.
• needs to have automatic migrations baked in
• develop code patterns that allow bridging to other db systems.

update function that automatically util.extends the node and calls save. should use fin's extend method to push to arrays instead of replacing them... or not. decide later. maybe toggle

Register async app functions that should run and complete before listening. eg: bootstrapping, environment configuration etc.

ability to specify indexes in the db schema. reduce query time on the backend.

note: this won't be needed on the front-end, front-end db cache only contains a small subset of data to filter through, and client generally has the capacity to perform those searches via brute force.

limit query results for BDD object filtering. called before sort() like where/and/or filters, executed by sort()

Sometimes the tail_api is unreachable. requests should be retried after some time.

• in some edge cases you may want a queue, but more likely you only care about retrying the last request. eg: navigating to page1, request fails, navigate to page2 (user gets bored and clicks another link) request fails, retry 2nd request only.. we're not on page1 anymore and don't care about that data.
• user is likely to go back to page 1 when the tail_api is reachable again (ie: data and templates can be fetched).
• requires further investigation. how does adding request to a queue to be retried later affect execution flow. should we only retry on nav? let custom code handlers handle themselves, etc.

create a mechanism for ajaxform's to automatically have csrf tokens generated and included. use jsonp to refresh csrf.

nav()'s getData should timeout, if it starts taking a long time it should show a message with an option to cancel.. or a clock, or something. tie into the loader/alert system

• support 'automated' migrations
• integrated into the _data object / persisted to goldfish.db
• add date field type with special values that update on insert and/or on update
• add ability to select columns (we don’t want client to get user’s password)
  • .select(col1, col2) will return a copy of the object with only those properties
    that way other functions still deal with the entire object
  • getResult() will use select() since it’s preparing data for the client
    will use select() with the schema definition for that object to filter out confidential properties.