Oh, if wanted the state directly in the DB, you'd presumably replace the
in-memory store entirely
So instead of:
---------------------------------------------
| routing | CLI | OVSDB | ReST | SNMP | etc |
---------------------------------------------
| State API |
- - - - - - - - - - - - - - - - - - - - - - -
| State |
---------------------------------------------
You'd do:
---------------------------------------------
| routing | CLI | OVSDB | ReST | SNMP | etc |
---------------------------------------------
| State API |
- - - - - - - - - - - - - - - - - - - - - - -
| Database interface glue |
---------------------------------------------
| Database Library |
---------------------------------------------
| Database |
---------------------------------------------
And you'd try keep the glue as stateless as possible, and you wouldn't
have any shadow copy of state, except to the extent your library can cache
things.
I don't intend to do that, but I think the state API should be
flexible/high-level enough to allow someone to implement that, if they
wanted.
?
What else? :)
regards,
--
Paul Jakma p...@jakma.org @pjakma Key ID: 64A2FF6A
Fortune:
If God had wanted you to go around nude, He would have given you bigger hands.
_______________________________________________
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev
