<pardon me for cherry-picking points from your message. Anything I didn't quote was "un"remarkable to me.>
On 8/17/2012 1:04 AM, Michael Haberler wrote: > how does that sound? anything essential missing? You've obviously thought about this much more deeply than I have. I was looking at it from my own experiences in a different distributed application. After two readings, I think your reply sounds very good. To me, the only "essentials" you didn't touch on were memory usage (see below) and performance and one has to have implementations to measure them. > mechanics & plumbing: > <...) > - the libhiredis-dev C client API (needed) starts with Precise only At first I read this as "the client doesn't work with lower versions" but then I realized it means "the package isn't available from the Ubuntu package servers for lower versions." > > With respect to package availability we have: > - 8.04 - no off-the-shelf parts I cannot justify hobbling new work with such old stuff. Ubuntu 8.04 was released April 2008. That means the long-term support for it dies next year, does it not? > > This means we're better off with a self-contained fork for now. My experience > is that the builds and self-tests for all three parts are harmless and free > of surprises. When all required packages are available for all supported > platforms, the code and build instructions can be taken out and replaced by > package requirements. This works for me. > community dependency: > there are many animals in the 'noSQL' jungle, coming from different genetic > backgrounds, many from web applications. I chose redis among other reasons > because it isnt tainted by Java, XML and other socially incompatible > technologies. I think lack of such taints is an excellent criterion. Simplest is best. > I dont think the redis work is endangered to fall out of favor soon. <...> The only way I see redis development being disrupted is for VMware to decide it has to monetize the work somehow. > startup: > the only open question IMO is whether the redis server should be > unconditionally started by all configurations (the redis process does next to > nothing on no traffic, and the memory requirements can be scaled down > substantially). I was going to ask about the memory usage. When I started up the redis server it told me it was using ca 500K bytes. That's not outrageous but it did seem a bit high. I like the principle of "least disruption" you implicitly invoked in arguing to start the redis server unless told explicitly not to. > runtime dependency: I see in the redis issues list a recent entry about an anomalous high latency induced in clients when the server is frozen. I expect that is being addressed but a test that a server is present and healthy may be required. > licensing: I read this as ok, I still would appreciate a second look at: I did too but I'm not a lawyer. I'll try to compare this license to the GPL 2/3 to see if I can glean any gotchas. > data model: > redis being one of the 'NoSQL' type databases needs a bit of a data model, > which in our case translates pretty much into 'organizing a namespace' (eg > interp/interp.params/tool/config etc). Ahh, there's the rub. I spent more than 20 years in the trenches fighting various data-model standardization battles (IGES/PDES/STEP/IFC). It isn't a pretty picture. All the information-engineering methodologies and software tools in the world won't stop stakeholders from disagreeing on what to call their data:-) We should allow for a plurality of approaches and move on. Your idea for compartmentalizing the results as far are code production is concerned seems quite workable. > features to be used: > Redis does many things, but the ones relevant for linuxcnc are: > - networked data structure storage with persistence : that I see as the core > feature to be used > - publish/subscribe interaction pattern: this is a very much needed > communications pattern not supported in a useful way by NML, and my code > example explored that. I would prefer that to be part of the messaging layer; > assuming that going forward we have a vehicle replacing NML which supports > that pattern it would not be a bright idea to have two different messaging > layers providing similar functionality. That said, I wouldnt prohibit its > use, but I suggest such use be thought through such that is isolated (say in > a module) and can easily be replaced. These two features are the attractions for me. I worked on such stuff in the context of "smart" buildings communicating with first responders (fire, police, etc.). It worked very well for me. > - persistence: some thought has to be given to import of existing emc.var > files, and manipulation/export from redis to an external file. Same goes for > tool table (no tool table format discussions in this thread, pleaaaaase.) Yup. This feature goes hand-in-hand with the first two and the evolution of EMC->EMC2->LinuxCNC2->LinuxCNC3. There should always be an external backup. > areas of applicability: > - my original motivation to introduce redis was to replace the constrained > tooltable communicated by Emcstat. This can be taken up again in a more > determined way. Not that it matters now, but I suspect the early lack of a hearty response from the developer community came from a sense that using redis was overkill for the tooltable example. It's so easy to think one can patch one's way out. > - the UI/interpreter parameter range idea recently proposed by Daniel Rogge > - if we are heading back to a fully distributed model in LinuxCNC, assuming > we have support by a decent middleware layer (this will be my suggestion for > LinuxCNC3), it does make sense to drop the 'all parts of LinuxCNC can access > an inifile' assumption because some parts of it, say a realtime embedded > backend, might not have a filesystem worth speaking of after all. In that > case, retrieving config information through redis is the way to go - on > startup, load the inifile into a redis namespace, done. A redis client api > can run on even very restricted environments. I like this fully distributed model but I'm not sure we have very concrete use-cases yet. > - userland HAL components come to my mind. Absolutely. --- Thanks for your detailed response. I feel very good about this. Regards, Kent ------------------------------------------------------------------------------ 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
