aboutsummaryrefslogtreecommitdiff
path: root/scripts/README
diff options
context:
space:
mode:
Diffstat (limited to 'scripts/README')
-rw-r--r--scripts/README73
1 files changed, 73 insertions, 0 deletions
diff --git a/scripts/README b/scripts/README
new file mode 100644
index 00000000..f0eb191e
--- /dev/null
+++ b/scripts/README
@@ -0,0 +1,73 @@
+$Id$
+
+
+
+At this point it's starting to look like the pdu objects in
+rpki.left_right are a subclass of a more general class of objects that
+live in SQL (duh). This makes sense as left-right protocol was
+designed to let us frob a subset of the rpki database on the wire.
+
+Hmm, it's more complicated than that. Most of left_right maps well,
+but portions (eg, <list_resources/>) are just commands and do not.
+Mixin? We have a varient of this same problem with the mixins I'm
+already using in irbe-cli.py.
+
+Also need to think about up-down protocol, currently separate but some
+of these objects might map there too. This is why I originally
+intended to code all of these as separate object hierarchies even
+though in some cases they look awfully similar. Hmm, implement as
+separate hierarchies with sideways conversion methods? Still feels
+wrong, but so does turning this into one big interconnected mess.
+
+Ok, up-down XML is all structured as commands, data is all attributes
+and (occasionally) element content, so not very close match to db.
+
+So this appears to break out fairly cleanly: objects shown in blue in
+the repository-engine-objects.pdf picture are both left-right PDU
+objects and database objects, objects shown in green are only database
+objects, and left-right PDU objects not shown in that picture are just
+left-right PDUs. Or something close to this, details need checking.
+So this does look like some kind of mixin would be appropriate.
+
+
+
+Code to pull in an entire self_id context at once turned out to be
+much too complicated. Replacement is more of a demand-paged design.
+Need to be careful about making sure we save out all changes between
+events, objects have a .sql_dirty attribute but I should also add a
+Python set object into which we can insert any object that needs to be
+saved when the current event exits.
+
+Haven't done anything about db.commit() and db.rollback() yet, for
+that matter haven't yet whacked MySQL to enable those features.
+
+Access to object data attributes really ought to be through accessor
+methods so that the .set() method can set the sql_dirty flag
+automagically. Not done yet.
+
+Hmm, do we really need .sql_dirty at all? Maybe just inserting the
+object into the dirty set (above) would suffice? One less thing to
+screw up.
+
+RelaxNG schemas probably ought to be internal rather than files with
+magic names or config variables pointing at files. Makefile hack to
+put a Python wrapper around a .rng file, and automatically convert
+.rng to lxml internal form while we're at it?
+
+Have started on RPKI-specific exception hierarchy (well, it might be
+flat) and conversion of inappropriate uses of assert and standard
+exceptions to use rpki-specific exceptions. Top level of protocol
+handlers needs to include exception catches that translate these
+exceptions into appropriate protocol error messages.
+
+Generalize serve_copy_hook() into serve_action_hook() and use it to
+handle actions signaled by the various left-right boolean controls.
+One fun test case for this should be bsc keypair generation.
+
+Some of the defined actions may be things we can't implement yet due
+to lack of a real timer system. Eg, the various "do this right now"
+actions are probably best handled as triggers, a la interrupt
+handlers. Well, maybe. IRBE folks might prefer a version that
+blocked response to the request until the whole cycle is done, once we
+have an event system that can treat the query and response phases of
+an rpc operation as two distinct events.