• Assessment: full stack build

  last modified July 26, 2007 by k0s

an assessment of work to be done moving towards the full stack build

This is mainly a chalk-board for me to keep trac of things that need to be done for this.  There's a lot to keep trac of, and so I'm going to use this as a sandbox


topp.build.lib


base.ini:
# To add: (in some form anyway)
sever = localhost

topp.build.deliverance

build.ini:
port = 4570 => deliverance_port = 4570

Add:
zope_uri = ${server}:${zope_port}/openplans
tasktracker_uri = ${server}:${tasktracker_port}/


 theman.ini needs some changes:
port = <<port>> => port = <<deliverance_port>>

zope_uri = http://localhost:8080 => zope_uri = <<zope_uri>> # this assumes you have zope setup
task_tracker_uri = http://localhost:5050 => task_tracker_uri = <<tasktracker_uri>> # note change in spelling
default_theme_uri = http://www.openplans.org # dunno what happens here. ltucker seems to know what's up

transcluder_ok_hosts = openplans.org|(.*)\.openplans.org|(.*)\.localhost.openplans\.org|localhost # move this to the build.ini?

theman.ini should ultimately be renamed something else, but for the Time Being this isn't causing any problems.

topp.build.opencore

this actually looks okay, partially because its the center of our multiverse

topp.build.tasktracker

build.ini:
port = 5050 => tasktracker_port = 5050

# filesystem location of protected data -- These should go up the chain -> t.b.l
secret = /var/lib/secret.txt
admin_filename = /var/lib/adminpw.txt

!--> the above
login_uri = http://www.openplans.org/login_form => ${zope_uri}/login
profile_uri = http://www.openplans.org/people/%s/profile => ${zope_uri}/people/

openplans.ini:

[openplans]
openplans_uri = http://localhost:${zope_port}/openplans/ => openplans_uri = http://${server}:${port}/openplans



development.ini:

port = <<port>> => port = <<tasktracker_port>>


General Discussion


I'm noticing some patterns here. Firstly, the 'extensions' of things: _uri, _port, -- this tells me there are general classes of things that we care about. 


Secondly, uri construction seems to be of the general pattern http://${server}:${port}/what/ever .  Sometimes the ${port} is ommitted, based on context.  Maybe there's a unified way of dealing with this.  Unfortunately, buildit is a bit limited regarding variable interpolation.  Maybe domain = http://${server}:${port} or something like that.

I'm also noticing a general pattern regarding uri's vs ports.  Assuming your stuff is on the same ${server} (our current setup, though a huge assumption), foo_uri usually equals http://${server}:${foo_port}/  Maybe the uri has some trailing stuff in which case we get into evil special cases.  Maybe there should be a mapper function for this.

Maybe its best to read each file individually, then modify the context.  port -> ${app}_${port}.  of course this is a lousy hack.  Maybe monkey-patching is better.


I'm also starting to see some need for unification of database work.   Maybe this isn't that important right now, but its worth thinking about.

Assessment:  buildit