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
>> 
>> 
>> ------------------------------------------------------------------------------
>> 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
> 
> ------------------------------------------------------------------------------
> 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


------------------------------------------------------------------------------
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

Reply via email to