Matt, Am 07.03.2013 um 17:26 schrieb Matt Shaver: ..
> be created. I don't however feel that the idea of a single, central > data store is a bad architectural idea. it's not just 'not a bad idea'. Consider the alternative - this whole thing becomes distributed again, into a realtime part, gui, maybe web. The alternative is a mess of configuration, log and state files littered over various machines, which may not even be of the same architecture or operating system to start with - I'm sorry, no. So this is on the table, just as before. > > What happened to all the really cool ideas about redis and 0MQ? I have decided to prioritize my activities after I fully understood what the status of RTAI is, and what the dependence of this project on RTAI as a single base of RT OS actually implies. As a consequence, I have postponed other work, and that included using redis as unifying state storage, for configuration as well as persistence. There is some work in mergeable state, namely interpreter persistence, but there is no point in persueing this as an isolated venture at this time. > I was > pretty jazzed about those things, and I think the answer to some of the > issues you raise (persistence) could be addressed in redis with a > messaging system to transport the state information to where it is > needed. The 'new RTOS' work is done to the extent I consider it usable without dangers of keeling over in a production setting. It also has proven to be portable to non-PC architectures. That is the status since mid-December, and only retouches have been applied since. It has also been used by others as a base for creative stuff, like emcweb, which brings home Sergey's work. This is currently waiting preconditions being ticked off for building packages, some of which are not within my control. I will however ascertain that this happens. An incremental improvement - the 'unified build' - a single binary build which will run on all (RT) bases unmodified will come later, say 2,3 months from now. The work plan for that is clear, key steps are resolved, it 'just needs to be done'. We've learned from the new RTOS work that 80% of the 'done' thing comes after coding is done. This has left time for me to continue work on the unified middleware theme - in a nutshell: HAL state propagation as well as current NML functionality, serialisation, 'web support' (aka automatic JSON translation) and other aspects like kernel threads compatibility. This work - which includes the ZMQ theme you refer to - has progressed well, and there is substantial off-list discussion and some review on some of the issues. There is nothing in the sense of a 'here's a branch, try it' result yet, but there are no major stumbling left blocks either - except licensing, on which I have not seen any tangible results coming out of endless list discussions either. In a sense, all this is nothing fundamentally new, it is a cleanup job behind obvious deficiencies of the current architecture, and tons of cruft which have accrued over the years. So this is not a weekend job either, and exceptional care has to taken towards compatibility as I rule out 'big bang changeover' scenario. I do not plan to come forward with half-baked things, so my next work item is to write up a paper and explain how these things will work together, from architectural considerations down to 'what does this mean when I write a component' and 'how will configuration change, and why'. -- To speed up work, collaboration has proven to work, so if anybody familiar/interested in those themes is willing to chip in at an early stage, drop me a note, also if it is just interest in what is going on. 'Discussed on the list' does not necessarily translate into 'productive consensus' and one does not have to look far for examples. An extremely valuable non-technical contribution to this whole effort would be to tackle the licensing issue with an angle to results in a realistic timeframe, and I would really appreciate if somebody else could take the lead on this, and actually deliver. This can be done in parallel, that is - now. - Michael > > Thanks, > Matt > > ------------------------------------------------------------------------------ > Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester > Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the > endpoint security space. For insight on selecting the right partner to > tackle endpoint security challenges, access the full report. > http://p.sf.net/sfu/symantec-dev2dev > _______________________________________________ > Emc-developers mailing list > Emc-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-developers ------------------------------------------------------------------------------ Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
