On 6/30/2013 10:36 PM, Chris Morley wrote: >> Date: Sun, 30 Jun 2013 22:25:20 -0700 >> From: d...@calypsoventures.com >> To: emc-developers@lists.sourceforge.net >> Subject: Re: [Emc-developers] toolstore discussion notes: Andy/mhaberler >> >> Andy, Michael, >> The network accessibility of the data store and the associated API is >> key to both providing and understanding the functionality that this >> approach could provide. >> Is there a proposed design document that lays out the API? >> Dave >> > Did you see this? > http://wiki.linuxcnc.org/cgi-bin/wiki.pl?ToolDatabase > > Andy has sample code he was using in Wichita. > I don't think he has posted that though. > > Chris M > I had seen that at some point in the past, but had not bookmarked it - so thanks for the reference.
However, that's not (I hope) the API layer that I was thinking about... If we move to a general data store facility, then some of the things that any such API has to support are establishing, initializing, manipulating and extending the info in the data store. The Wiki page looks more to me like an example of how a data store might be set up where the tool data model is based on tables and table relational operations. It may even be the default way that a "tool store" is set up for LCNC once this change is implemented. The tables in the wiki page appear to me to have been structured so as to make relational data base operations convenient with them. That's fine, though it does seem to let the underlying SQL implementation show thru - the wiki page data structures are table oriented and seem to imply RDBS operations (union, intersection etc) on tables that are indexed by key fields etc). When designing APIs like this, the underlying data store implementation tends to show thru in the API - and that can be OK depending on what you need to accomplish. What I'm looking for is the base functionality of the proposed API that would be used to create and manipulate the data store. If we assume the store is table centric then I might expect to see things like: define tables and fields; query tables etc. In contrast, I got the impression from Michael's email notes that the API level is not intended to be SQL table centric - so I'm interested in reading the API primitives to see what type of abstraction is being proposed. The reason I am interested in the API layer is that I really want to see an extensible and (at a minimum) integrator configurable tool handling facility. (I think it would be a shame to make this much change and not end up with a extensible tool data store.) Frankly, skeptical that it's possible for LCNC to think of and anticipate all the ways such a generalized data store facility could be used - even for just the "tool table" subject. For example, my current CNC system utilizes additional tool attributes that I've created. These are logically attributes of tools and/or tool/tool holder combinations. I'd not immediately argue that these should be part of a default LCNC tool data store (as they would not be of general interest to many). Even if they were part of the new "tool table replacement", something else would come along later that was not included today. Thus, I find myself wanting to know that it will be possible (in general) to create what is/may be needed by using the proposed "network API to the data store". I'm simply using my current tool attributes as a convenient test case / evaluation tool. Thus I figure the way to evaluate what can be supported is with this "network accessible data store" to look at the base API being proposed and evaluate the API proposal wrt to abstraction model, flexibility and extensibility. I'm a top down type of guy in this case - Ideally I'd like to sit down and read a) the functional goals for a replacement "tool info blob" (What does the data store have to accomplish and why) and b) the data store API spec (which would show the details of the set of APIs that implement the goals called for in a). Dave ------------------------------------------------------------------------------ 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
