I still wonder if the Plan9 File System (which is now supported in the Linux kernel) would be simpler. I will look into ZeroMQ to make sure I understand the issues, but it being GPLv3-only may or may not be an issue.
As for ini files not supporting types and dereferencing... I've considered more than once recently adding a #include and VAR.type primitives to a generic .ini parser. I am wondering if there are similar features in publically avaible libraries such as inih <http://code.google.com/p/inih/>. Reading up on the ini file format (http://en.wikipedia.org/wiki/INI_file) I see that many people have moved to XML for configuration files. Maybe that would be an alternative too. Maybe I am missing something here... Not sure though. EBo -- On Sat, 18 Aug 2012 00:06:09 +0200, Michael Haberler wrote: > Am 17.08.2012 um 22:47 schrieb Jan de Kruyf: > > Hi Jan, > >> Michael, hallo. >> Here is a way out question: >> In a distributed system would you see your way clear to do the whole >> setup of a headless station from the database? >> I.e. store (pointers to) the specific HAL code, ini files, etc in >> the >> database and distribute on power-up? > > IMO this question is not at all 'way out', but rather practical. I > think this is the way to remove the common file system assumption for > configuration. > > As for sizes, Redis value size limits are way beyond any conceivable > object sizes used in LinuxCNC configurations, like HAL cmd files. > This > would need a bit of organizing the Redis data model, loading the ini > file section/key/value pairs at startup (easy) and dereference the > files in there (i.e. read and load these files as well). The only > issue that prevents that from being brain-dead automatic is the fact > that ini files dont have type information (like 'this key is an int', > 'that key is a file and needs loading a.k.a dereferencing'). But > thats > minor. > > As for client footprint - the code size of Redis C API library: > > ~/emc2-dev/src/redis/redis/deps/hiredis$ size *.o > text data bss dec hex filename > 7106 24 0 7130 1bda async.o > 12801 20 0 12821 3215 hiredis.o > 2647 0 0 2647 a57 net.o > 4623 0 0 4623 120f sds.o > > gut feeling: out of reach for Arduinos (esp since the TCP stack is > not yet included), perfectly fine for RaspberryPI class devices and > up > > -- > > I am jumping the licensing gun now, and it is not a pressing problem > for LinuxCNC. > > But assuming we had zeroMQ available: IMO the way to make such > 'outboard devices' completely configuration-information-free the way > to go is to have a client subscribe to a zeroMQ pgm multicast to > learn > the gory details (config server etc), similar to avahi-demon; just > reliably: > > look at https://gist.github.com/1046938 and replace > > socket.bind('tcp://127.0.0.1:5000') > with > socket.bind('epgm://<interface>:<address>:<port>') > > do the same to https://gist.github.com/1046936 on the state/config > carrying 'host' to, say, export the redis URI, done. > > -m > > >> >> j. >> >> >> On Fri, Aug 17, 2012 at 8:21 PM, Michael Haberler >> <[email protected]> wrote: >>> >>> Am 17.08.2012 um 19:03 schrieb Kenneth Lerman: >>> >>>> On 8/17/2012 12:42 PM, Kent A. Reed wrote: >>>>> <pardon me for cherry-picking points from your message. Anything >>>>> I >>> ... >>> >>>> Don't take the lack of a hearty response from the developer >>>> community >>>> negatively. Most of us will speak up if we disagree. >>>> >>>> At any rate, using a database seems fine to me. A noSQL database >>>> seems >>>> appropriate. An if *you* (Michael) think Redis is the one to use, >>>> I >>>> trust your judgement. (Particularly since Kent seems to agree.) >>>> >>>> Regards, >>>> >>>> Ken >>> >>> That's very good noises;) >>> >>> So I think step one is this branch: >>> http://git.mah.priv.at/gitweb/emc2-dev.git/shortlog/refs/heads/redis-integration >>> >>> This will be the basic Redis development environment until the >>> packages are available. When this is a safe bet, everything under >>> src/redis/redis and src/redis/redis-py can be dumped. >>> >>> This includes snapshots of redis-server and C API, and the redis-py >>> Python bindings, integrated with LinuxCNC configure and build. Also, >>> a C example including Submakefile, and a simple Python sample. It >>> does not modify any LinuxCNC code to actually use it - this is the >>> plumbing branch. >>> >>> Currently the configuration options WRT to redis are 'yes' and >>> 'yes', but that can be patched. >>> >>> the linuxcnc startup script starts/stops the server automatically. >>> >>> The branch is off master; tested on 10.04 and 8.04, both RT and >>> simulator, 2 machines. >>> >>> README: >>> http://git.mah.priv.at/gitweb/emc2-dev.git/blob_plain/f4e198cfc1d9f73556b6364f485a7df346f638ec:/src/redis/README >>> >>> to run the demos, see src/redis/examples - the C example integrates >>> with build. >>> >>> --- >>> >>> this is a LOT of code - I would appreciate a few other eyeballs >>> before merging this into master. >>> >>> - Michael ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
