Am 03.05.2011 um 16:27 schrieb Chris Radek: > On Tue, May 03, 2011 at 09:28:43AM +0200, Michael Haberler wrote: ... >> tooltable replacement: tooltablev2 will get a decent abstract data >> type, implemented with an sqlite3 database, and move from iocontrol to >> task and interp, handled through Python callouts. Actual logic will >> move to Python and sqlite3 procedures. This is disjoint from remapping >> G/Mcodes since the tool-related change primitives are needed anyway - >> just potentially a lot more powerful. > > I do understand some of the reasons you want to move tool table > handling out of iotask (and possibly eliminate iotask altogether) > but I do not see why it should be a database. Can you expand on why > you think this is the thing to do?
I understand it's unwise to force a change on every user for the sake of a *storage format* change. Nevertheless I think there are very good reasons to use a database, and I'm happy to explain my reasoning for that, but will do so in separate mail as it will be longish. Having rethought it, what I plan to do instead is encapsulate all existing code worth retaining relating to: - storage and manipulation of tool information - changer specific operations as far as they absolutely have to be supported at the C/C++ level (eg potentially NML work), into a class. This class interface will use a 'published API' and will go into a shared object module. It can be replaced if one so wishes but nobody has to. I plan to use sqlite3, and potentially embedded Python, in a different module, using this very API, which can be used optionally. This approach retains current data format, vi editing etc for all which wish to do so, and it enables an API which can be used to go well beyond what is currently possible for those who need it. So, let me spell out here what I expect to be the user-visible damage to everybody of this approach should be (ha!): # the tooltable/toolchange support code has moved to a plugin # you load your favorite plugin as follows: [RS274NGC] TOOLCHANGER_SUPPORT=/path/to/v2.5-tooltable-support.so #TOOLCHANGER_SUPPORT=/path/to/michaels-really-whacky-vehicle-which-uses-sqlite3.so # # if you dont like it, use the API documented <here> and start from the example <there>. I think the design of this API/class, and embedding it in task and interp, including weedout of existing internals dependencies, will be a very cathartic cleanup exercise. --- Let me add a more philosophical observation to think about: I am not aware of any successful piece of software of the last decade which does not support plugins or at least an API. Moreover, some of them have basically become plugin carriers with some core functionality, e.g. Python or Firefox. Most of EMC is like that - it is stunningly modularized at the level of realtime and user-level modules. The support for user module creation is superb and very simple to use. HAL is an excellent abstraction and robust base easing plumbing and wiring of almost arbitrary gear. The user interfaces rely heavily on loaded modules, although not really an API. I note that milltask (all of task and the Interpreter) barely have any of these attributes, and it might be useful to think about how deficiencies in that area could be alleviated through use of plugins and APIs here as well. -m ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
