Am 17.05.2013 um 21:06 schrieb Dave <e...@dc9.tzo.com>: > > I like the idea of a database.
let me reiterate: we are talking about a _data model_. We are not talking about a _database_, which is a storage mechanism for a particular data model implementation, and I have not proposed any. The deliverables of the whole exercise IMV should be: - all tool-related data is to be held in a toolstore (note lack of 'db' in the term) - all using entities, including interpreter, UI, and motion, have ways, by means of a public API, to access and change those aspects of tool data they need - 'they need' translates into views - the interpreter has - due to lookahead - a different view than the machine proper - the toolstore is an 'Abstract Data Type', which means: it is defined through the methods it supports. A using entity doesnt know and doesnt care how data is stored internally (which is why the 'db' has no place here) Now obviously a complete working system needs to have a concrete example toolstore to have something working. That could be anything really, redis, mysql, and something needs to be there but that AFAIC this is an integrator choice; the distribution should supply one mechanism of course. > However, realistically, how many > people/users are going to want to apply the wear offset from one tool to > a different tool?? Bang, trapped again. You simplify an implementation; you never simplify the model proper because that gives you the power to describe the complex _and_ the simple. Note: the mess we have now is the result of 'going simple and optimizing the common case' too early. And: none of you folks will have any issue understand what these tables and their contents mean, in the remote case you actually want to see them: tool, offsets, tool magazine, holders - you wont need much tutoring on the meaning. A particular implemtation, which might be a database, might bring a new syntax _at the storage level_ but again the using level is fenced off by an API so that is largely irrelevant except for import/export btw I am pressed to envisage a very complete data model for LinuxCNC tool miniworld which has more than maybe 10 tables > Is that a requirement/desire by someone?? > It seems like an overkill and could result in user errors and > consequently machining errors. That whole stuff we're discussing here isnt user visible to start with except for features which are impossible now; it might be integrator-visible though (sorry ;) > The general question I am raising...is > how flexible do we want the tool table/offset/wear offset table/database > to be? Well I think we better start at a model being capable of supporting what already exists or would be nice to have shortterm in a meaningful way, and without 'flags', magic meaning of key values and digging around in C code - and there's a lot to do here - i.e. cleanup I'm not even talking about blue sky which might be multiple changer magazines, multiple spindles or somesuch > If it is made too complex, we risk a lot of confusion regarding the > proper implementation of the tool table. I'm thinking that if the > manual section of configuring the tool table is 20+ pages long, that > will be a problem and the common LinuxCNC user will avoid altering the > tool table at all costs. I think the circle of affected persons is a) the folks doing the API and the standard toolstore b) the folks doing a toolstore implementation with a non-stock storage mechanism I would think the maximum integrator impact is a different import/export file syntax as for the a) and b) folks: you need to tick a box. The dog 'a simple flat tool table file which supports arbitrary changers, offset, holders, spindles' etc has been proven not to hunt - Michael > > > ------------------------------------------------------------------------------ > AlienVault Unified Security Management (USM) platform delivers complete > security visibility with the essential security capabilities. Easily and > efficiently configure, manage, and operate all of your security controls > from a single console and one unified framework. Download a free trial. > http://p.sf.net/sfu/alienvault_d2d > _______________________________________________ > Emc-developers mailing list > Emc-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-developers ------------------------------------------------------------------------------ AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
