This is a short summary of Andy's and my discussion of the issue at Wichita, and several longer offline discussions before that. It sketches how in the future the handling of tool information (and likely all persistent data) will be handled in LinuxCNC.
1. the storage and retrieval of all tool related information, and other persistent values in linuxcnc will be move to a server process, tentatively called toolstore. 2. the toolstore server will be the _only_ place to store any persistent data in linuxcnc (this is a bit wider scope that just "tooltable replacement"); in particular persistent parameters, but possibly also configuration information (again, due to a future distributed setup remote access to config data becomes a theme). 3. this server process will be accessible over a networked API consisting of request/response sequences of messages, which will be defined in the protobuf format, and transported over zeroMQ sockets. There will be no NML version of this work. 4. the networked API is needed because the entities relying on the information stored might not reside on the same host. Such entities will include, but not be limited to, the interpreter, HAL components dealing with tool information, UI elements for viewing/changing tool related information etc. 5. entities accessing the toolstore might request, and operate on, different views of the same data, in particular machine view and readahead view. There will be an API primitive to synchronize views as needed (see also 8). 6. The semantics of the toolstore is defined by the API, and we envisage the toolstore server process to be done in Python, having found no good reason for C++. Note that does _not_ prescribe how information will actually be stored, which is an implementation aspect of the toolstore server, and might well be different subject to needs and integrator discretion. While for the purpose of designing an encompassing data model a particular route (sqlite3 and a relational data model) have been chosen for good reasons this does not dictate in any way what is being used at the storage level. 7. Since iocontrol will not manage any persistent state any more, its role will evolve into a scripted interface to the toolchange process and exclusively that (HAL pin prototocol as needed); in particular we believe it should become a piece of Python amenable to integrator adaptation; there is no good reason left to retain a blob of rather immutable C++ for the remaining purposes. There might be very well different 'iocontrols' as needed to support a particular change process. 8. It might make sense to consider this proposal in the context of this work: http://wiki.linuxcnc.org/cgi-bin/wiki.pl?QueuebustersRevisited - what it would yield is a completely language-independent way of treating state information, which would ease implementation of a new interpreter, or different languages downstream. - Michael ------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
