On Wed, 2011-01-12 at 15:31 -0500, Justin Ross wrote: > ... > > Summary > > > > Brokers write simple name-value pairs, one to a line, into PID > > files in /var/run/qpid. The names are tree-structured. Files are > > updated periodically, and taken down when broker shuts down > > normally. This allows easy discovery of broker info by any > > script or program. > > I might consider dropping the tree-structured names part. Based on my > experience with java properties files, I find people tend to be confused > as to whether ".", for instance, is a word separator or a parent-child > operator. The result is a big mess. > > I see two options: decide up front that data with an implicit tree > structure is not necessary and remove the language about trees, or switch > to a format that truly supports nested data (json, yaml, etc.).
I'm not wholly convinced by Justin's argument, but you must specify the file format including the separation of the hierarchy - Justin has assumed the separator is "." which is consistent with many other config files. However Mick seems to have used "_" as his separator. I note that you could have flat name space that looks like a hierarchy merely by allowing a de facto separator character to occur in the names. > ... > > Implementation Notes > > > > I think this is dead easy, in its first impl. make a class > > called something like ... infoPublisher ... or something. Make a > > public instance of it in the Broker. Anything in the code that > > can reach the Broker can call broker->infoPublisher ( name, > > value ); And that pair will get written out to the appropriate > > file. You can make it either replace any previous instance of > > that attr-value pair in the file, or just append this latest > > line to the end of the file. This code would be in > > cpp/src/qpid/broker . /em> > > I find the alternative append behavior surprising. I tend to think it > should be simpler: there's a map in memory, and sometimes it gets written > to disk. > I find the append only behaviour fairly reasonable - it would act as a journal. It's easy to implement by the broker - just write out a single new line whenever something changes. A reading program would have to read every line and allow subsequent lines to overwrite existing values. As Justin notes if you write out the whole map to some trigger than you have to figure out what that trigger might be. Andrew --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:[email protected]
