Hi, thomas:
Yes I think there are plenty of distributed hash table implementations
available, that could work as a starting point.
There are a number of issues to consider, however, that will require
coordination around this DHT.
First, there must be a way to find instances. It doesn't help to store
and share them if you cannot find the I'd of the thing you want.
Second, you must deal with the creation of the ids-- which must be
globally unique, and thus I suspect created by an algo more complex
than an int.
I think it would be easiest to start with essentially a client server
model, where the server is a web-based instance repository, and
essentially have the cad api interface with this repo. This repo
should have ability to connect to other repos in a way that allows
them to see objects in the others to which they are connected. In
this way, people could set up a local repo if they wish, or connect
directly to a public, already available repo. In the most
sophisticated model, they would have a repo connected to several
others they are collaborating with.
I think the above model would be easy to set up and develop, but would
scale nicely.
On 12/15/10, Thomas Paviot <tpav...@gmail.com> wrote:
> Thank you Dave for all these explanations.
>
> After all, the semantics and technical layers of the high level CAD API have
> to be independent, and many different solutions could be studied in order to
> deploy these API over a network, whether it is 'small' or 'big', centralized
> or not etc.
>
> In my opinion, the key concept of the OMG CAD Services as they were released
> in 2003 (v1.1) and 2005 (v1.2) is the handling of CAD instances by their
> identifier. In that sense, it is quite close to the way the STEP standard
> defines the serialization of a population of entities (STEP Part 21): each
> instance is associated to an integer (unique, of course) that maps to the
> instance definition. For instance, here is how a vertex can be defined from
> a cartesian point (AP203):
>
> #437=CARTESIAN_POINT('',(-9.75E1,-2.E1,-1.299038105677E1));
> #438=CARTESIAN_POINT('',(-8.75E1,-2.E1,-1.299038105677E1));
> #439=VERTEX_POINT('',#437);
> #440=VERTEX_POINT('',#438);
>
> The same idea is used in the OMG CAD Services spec.
>
> I think this way to handle instances is very convenient for a networked API:
> rather than exchanging instances (and have, as a consequence, huge WSDL
> files describing data types), you just exchange integers. Embedded into a
> XML file, and transfered through http, these handles could then become
> lightweight 'messages' (as far as I understand your explanations).
>
> The second point is that each id must be associated to its value, in order
> to be processed by the 3D kernel. As a consequence, the key-value mapping
> must be stored somewhere. In python, it's obvious that the dict is the
> perfect solution for such a mapping, for instance:
>
> d={}
> d[437]=my_cartesian_point
> d[439]=my_vertex_point
>
> The hash table, stored in a python dict, could also be made available over a
> p2p network that are suitable to deal with Distributed Hash Tables (DHT).
> However, the serialization of the instance has still to be done in order to
> make it understandable to any peer.
>
> Conclusion : one could imagine a Hash Table based high level CAD API. This
> underlying hashing architecture can be abstracted for the python user (just
> imagine a kind of superclass embedding both the instance and its uid handle,
> the uid being never shown to the python developer) and, at the same time,
> would be ready for a networked deployment of the API, whether it is
> centralized or distributed, message or WSDL based.
>
> Thomas
>
> 2010/12/14 Dave Cowden <dave.cow...@gmail.com>
>
>> Hi, Thomas, no problem, i'm happy to help with this.
>>
>> Yes many MOM servers are fairly 'lightweight' and could run in process so
>> that another separate app/server is required. It is also possible with
>> many
>> of them to set up a group of 'federated' nodes, that forward messages to
>> each other.
>>
>> However, I suspect that this will not be a good fit, as I mentioned.
>>
>> I think a central question you need to answer is whether in the system you
>> envision, whether there would be _any_ central authority. Would it be
>> sufficient for the system to allow one person/entity to define a project,
>> and then allow people at any location to easily contribute/modify/add to
>> its
>> pieces? If this is sufficient, then it seems most reasonable to coordinate
>> access through a single server using internet-based protocols. In this
>> category, i think standard REST-based apis coordinating through a single
>> server would be sufficient.
>>
>> If it is not sufficient, then the requirements include the ability for any
>> client to share and assemble components from parts defined by anyone else,
>> without the need for a central repository. This is where you would want
>> to
>> use git, gnutella, or some other p2p product as a model. This would be
>> cool
>> but I would be really surprised if it became a practical need. I think in
>> the end a group of humans will decide to collaborate, and when they do
>> they
>> can decide to coordinate with a single server. As long as it is easy to
>> set
>> up, that will be fine.
>>
>> On Tue, Dec 14, 2010 at 11:20 AM, Thomas Paviot <tpav...@gmail.com> wrote:
>>
>>> Hi Dave,
>>>
>>> The final objective might be larger than initially expected, but as usual
>>> I'd like to go on with pragmatism without waiting for years before having
>>> any code to run/test/execute.
>>>
>>> The MOM architecture, as you describe it, could eventually be a problem
>>> for our purpose. For instance, if we develop a small set of CAD functions
>>> that use this technology, in order to test a simple collaborative use
>>> case,
>>> we would have to set up a 'hub' server dedicated to messages
>>> exchange/routing, right? I could host it on my machine, but it would not
>>> be
>>> very convenient.
>>>
>>> Furthermore, if you think about a big network, composed for instance of
>>> several hundreds machines exchanging messages with the hub, don't you
>>> think
>>> this 'central' server could create a bottleneck? Another point: the
>>> failure
>>> of the central server can make the entire network collapse (i.e. the
>>> messages cannot be processed/transfered by the hub). This hub is then a
>>> weakness in the network, no?
>>>
>>> I still have one more question: could the function of the hub be
>>> distributed over each peer?
>>>
>>> The idea to use an working and successful system, such as git, is
>>> interesting. I hade a look at distributed source version control tools
>>> such
>>> as Bazaar or Mercurial (python based), not git. But I never switched to
>>> any
>>> of them for a development project, and I don't really know how they're
>>> working. But I have the feeling that they are suitable for distributed
>>> file
>>> storage management, but not really for asynchronous work with a small
>>> time
>>> constant.
>>>
>>> Maybe my questions/remarks are stupid, just tell me!
>>>
>>> Thomas
>>>
>>> 2010/12/14 Cowdens <dave.cow...@gmail.com>
>>>
>>> Hi, Thomas,
>>>>
>>>> You have amazing vision! You have set your crosshairs on a larger
>>>> problem than I first imagined.
>>>>
>>>> Regarding your scaling point:
>>>>
>>>> MOM solutions are architecturally a 'hub and spoke' model, in which all
>>>> clients talk to a central server, ( or cluster of servers). Because the
>>>> clients all talk to a well-known central server, they do not need to
>>>> know
>>>> about each other. A typical benefit of this architecture is
>>>> publish-subscribe, which allows one-to-many messaging in addition to
>>>> point-to-point messaging. In the enterprise, i really like this
>>>> architecture.
>>>>
>>>> However, in your vision, a central server will be problemmatic. If you
>>>> desire easy and wide reaching collaboration, peer-to-peer is more likely
>>>> to
>>>> work,i agree.
>>>>
>>>> Along the lines of not re-inventing the wheel, it might be good to model
>>>> the distributed nature of the product on an already successful system. A
>>>> good is git, a distributed source control management system. I would
>>>> imagine that the task of keeping a distributed assembly updated when in
>>>> use
>>>> by a lot of people is similar to the task of keeping a source tree
>>>> update
>>>> when in use by a lot of people, and git does exactly that. Git is
>>>> designed
>>>> to allow collaboration of lots of people across the internet, without
>>>> the
>>>> need for a cental server.
>>>>
>>>> Perhaps the distributed idea of git could be combined with a CAD api in
>>>> a
>>>> way that a distributed assembly could be built in much the same way the
>>>> linux kernel is built? In the case of git, the 'api' is all about file
>>>> management, but i could see a parallel set of functions to manipulate
>>>> objects and assemblies....
>>>>
>>>> ------------------------------
>>>> *From:* pythonocc-users-boun...@gna.org [mailto:
>>>> pythonocc-users-boun...@gna.org] *On Behalf Of *Thomas Paviot
>>>> *Sent:* Tuesday, December 14, 2010 3:57 AM
>>>>
>>>> *To:* pythonOCC users mailing list.
>>>> *Subject:* Re: [Pythonocc-users] Anyone seen this?
>>>>
>>>> Hi Dave, Stephen,
>>>>
>>>> Thank you for sharing your opinion and you expertise. Here is my answer
>>>> to your recent posts, that I will discuss from a 'consistency'
>>>> viewpoint.
>>>> The last point is rather the expression of a very personal thinking.
>>>>
>>>> * global semantics consistency:
>>>> I completely agree with Stephen about the use of ontologies, and
>>>> especially the Ontology Web Language (OWL) to generate (infer?) the
>>>> informational model of an high level CAD API. The most pragmatic way to
>>>> progress in that way is to use the semantics that is the output of a
>>>> large
>>>> consensus, rather than defining a new semantics from scratch. A good
>>>> point
>>>> to start with would be to harmonize the OntoSTEP [1] ontologies and a
>>>> kind
>>>> of 'CAD services ontology', that is still to be defined. According to
>>>> Stephen, the work already achieved by the OMG CAD Services can be
>>>> considered
>>>> as a semantics mine in which we can grab a few concepts/ideas. It's a
>>>> pragmatic idea: let's not reinvent the wheel and use the work already
>>>> achieved, even if it's not perfect and need to be updated to latest
>>>> technologies. We take the best, we leave the rest, it makes sense.
>>>>
>>>> * multi scale technical consistency:
>>>> Many people here, on this ml, have requested for a high-level API
>>>> intended to abstract the OCC data model, which can be considered to be
>>>> too
>>>> granular to be used as-is. The basic need is then to provide a python
>>>> API,
>>>> on top of the OCC python wrapper, that would call a 'local' API: the
>>>> python
>>>> developper just imports a 'High level CAD' module, or package, that he
>>>> can
>>>> use for its own purpose. This was the initial idea: one, two or more
>>>> people
>>>> defines a set of classes/functions/methods (a draft is available in the
>>>> pythonocc 'addon' directory). However, the scope of this work is limited
>>>> to
>>>> the users of pythonocc who contributed the API. Other users may not find
>>>> what they're looking for and then built their own functions. That's why
>>>> I'd
>>>> like to open the thinking about this high level CAD api to a wider scope
>>>> and
>>>> set of needs:
>>>> - the 'local' API is certainly a requirement. Everyone should be able
>>>> to use the set of defined CAD API from it's machine
>>>> - this 'local' API should be also used to enable exchange and sharing
>>>> of CAD data generated from this API. For instance, imagine two people,
>>>> both
>>>> running a pythonOCC based program on their machines, and working on the
>>>> same
>>>> shape/assembly. It would be a small network CAD workflow;
>>>> - furthermore, what is possible to two people could be extended to a
>>>> set of n pythonocc users working together.
>>>> That is what I call a 'multiscale architecture', suitable for local to
>>>> wide network CAD workflows. i.e., the architecture must be highly
>>>> dynamic
>>>> and scalable. The current network architectures for collaborative CAD
>>>> activities are, in this sense, 'inconsistent': many local CAD kernels
>>>> connected to one or more PDM systems worldwide replicated to deal with
>>>> high
>>>> network loads and lags. The server/client architecture may not be the
>>>> best
>>>> solution, and one could think about a distributed architecture similar
>>>> to
>>>> peer-to-peer. Im' not familiar with Messages Oriented Middleware (MOM),
>>>> but
>>>> both of you talked about it, and I also already heard of it from other
>>>> people I use to work with. I still don't see/feel the difference between
>>>> MOM
>>>> and RPC technologies (I include SOAP/WSDL into the RPC scope) and have
>>>> to
>>>> study it deeper than just reading the wikipedia webpage.
>>>>
>>>> * last point: why this work should be close to open standards?
>>>>
>>>> If we manage to get something working, both from a local and global
>>>> viewpoint, with a highly abstracted API, we could dream of an
>>>> implementation
>>>> of such this API on top of famous CAD softwares, and imagine
>>>> collaborative
>>>> CAD workflows involving different softwares. I agree with Dave's
>>>> arguments:
>>>> proprietary vendors do not have any interest to make their products
>>>> interoperable with the ones from their competitors. That's why, in my
>>>> opinion, the battle field is the standardization: if the pythonocc high
>>>> level API can contribute to the standardization of a CAD Services API up
>>>> to
>>>> date with latest technologies and network architectures, scalable,
>>>> dynamic,
>>>> secure, then in the long term, under the pressure of their big
>>>> customers,
>>>> CAD vendors might be forced to implement such an API. An utopia?
>>>> Absolutely!
>>>>
>>>> Well, let's go with another possibility: enabling the forming of a such
>>>> a
>>>> wide networked CAD system, consistent and CAD software independent,
>>>> would
>>>> make possible the collaboration of many people all around the world. A
>>>> free
>>>> and open source software that implements this API would explode the last
>>>> wall: licensing issues of commercial and proprietary CAD software. With
>>>> this
>>>> last wall falling down, one could dream of a kind of 'Free and Open
>>>> Product
>>>> Development', exactly on the same model than the 'Free and Open Source
>>>> Software Development' has emerged a couple of decades ago. Imagine new
>>>> wind
>>>> turbines, cars, buildings etc., designed by talented engineers located
>>>> all
>>>> around the world and working together on product development projects,
>>>> available at no cost, for everyone, in order to be manufactured. The
>>>> benefits from such a product development model would be the same than
>>>> the
>>>> ones provided by free and OSS over proprietary software: you are free to
>>>> study/redistribute/modify/sell product data, and
>>>> manufacture/commercialize
>>>> the product. An utopia? Absolutely!
>>>>
>>>> Thomas
>>>>
>>>> [1] Krima, S., Barbau, R., Fiorentini, X., Sudarsan, R. and Sriram, R.D.
>>>> "OntoSTEP: OWL-DL Ontology for STEP",
>>>> http://www.nist.gov/manuscript-publication-search.cfm?pub_id=901544,
>>>> NIST, 2009.
>>>>
>>>> 2010/12/13 <dave.cow...@gmail.com>
>>>>
>>>>> Hi, Steve:
>>>>>
>>>>> I'm definitely in agreement with you about CORBA/SOAP. I'm a huge fan
>>>>> of
>>>>> MOM solutions as opposed to SOAP and such. HTTP tends to have some
>>>>> benefits
>>>>> when interacting with services over the internet ( B2B ), but that is
>>>>> really
>>>>> just because nobody has proposed a good MOM-over-HTTP spec that
>>>>> everyone can
>>>>> agree on yet.
>>>>>
>>>>> The big decision, of course, is whether to define an API in terms of
>>>>> essentially function calls (like IDL ) or 'messages' -- which an have
>>>>> an
>>>>> arbitrary structure, but are basically transport independent. Though I
>>>>> find
>>>>> MOM architectures are more scalable and flexible, they tend to be
>>>>> overkill
>>>>> when most of the system will be running in-process anyway, which seems
>>>>> likely in this situation.
>>>>>
>>>>> One other thought to throw out in this topic is the 'analysis
>>>>> paralysis'
>>>>> issue. Though it would be good to build on the work of others, and to
>>>>> be
>>>>> consistent with existing specs in order to ensure widest adoption,
>>>>> sometimes
>>>>> a spec that's actually implemented but less than ideal is the best
>>>>> choice.
>>>>>
>>>>> As I see the issues discussed, I'm thinking more and more that it be
>>>>> best to just make some reasonable decisions on how the API works and go
>>>>> with
>>>>> it. Perhaps this could be loosely based on the OMG spec to start with,
>>>>> but I
>>>>> don't think its likely much will be gained by sticking to it. PythonOCC
>>>>> is
>>>>> strong, and AFAIK is the most advanced of all the open source kernels.
>>>>> Sticking with a CORBA- based API will likely limit the flexibility that
>>>>> a
>>>>> pure python based library could offer. I don't think it is necessary to
>>>>> be
>>>>> able to interoperate with other companies or systems to be successful.
>>>>> There
>>>>> is a good chance that the mainsteam modelling kernels will not publish
>>>>> an
>>>>> API that conforms to a standard interface anyway, they will want a
>>>>> proprietary API to lock in their customers.
>>>>>
>>>>> My gut feeling says the best approach is to look at the OMG spec to
>>>>> understand the issues and learn about the problem domain, then design
>>>>> an API
>>>>> that works well with pythonOCC and move on it, not worrying from that
>>>>> point
>>>>> whether it is OMG compatible or not.
>>>>>
>>>>>
>>>>> On Dec 12, 2010 6:47pm, Stephen Waterbury <water...@pangalactic.us>
>>>>> wrote:
>>>>> > On 12/12/2010 04:44 PM, Thomas Paviot wrote:
>>>>> >
>>>>> >
>>>>> > Dear Steve,
>>>>> >
>>>>> >
>>>>> >
>>>>> > The OMG CAD Services (OCS) specs are still freely available from the
>>>>> OMG
>>>>> >
>>>>> > website (the latest release is 1.2 : http://www.omg.org/spec/CAD/).
>>>>> >
>>>>> >
>>>>> >
>>>>> >
>>>>> > Thanks, I just removed the 1.1 doc from my site! (I had a local
>>>>> >
>>>>> > copy and hadn't bothered to check whether OMG still had an
>>>>> >
>>>>> > accessible version of the spec.)
>>>>> >
>>>>> >
>>>>> >
>>>>> >
>>>>> > I agree
>>>>> >
>>>>> > with you about the fact that the OCS is a good starting point. I
>>>>> briefly
>>>>> >
>>>>> > studied the OCS some months ago, and have a few notes I'd like to
>>>>> discuss with
>>>>> >
>>>>> > you:
>>>>> >
>>>>> >
>>>>> >
>>>>> > * from a technical viewpoint, the CORBA technology is perfectly
>>>>> suitable
>>>>> >
>>>>> > for synchronous sharing of business objects through a network. In
>>>>> my
>>>>> >
>>>>> > opinion, an asynchronous collaboration should be enough (regarding
>>>>> the
>>>>> >
>>>>> > business needs related to usual CAD workflows) and Web Services
>>>>> (WSDL,
>>>>> >
>>>>> > SOAP etc.) might just be perfect;
>>>>> >
>>>>> >
>>>>> >
>>>>> >
>>>>> > I find CORBA a bit "heavy" compared to some more recently
>>>>> >
>>>>> > introduced technologies, and nowadays I don't think of OMG specs
>>>>> >
>>>>> > as implying CORBA implementation, albeit they are still defined
>>>>> >
>>>>> > using IDL (which I kind of like). I must also confess an
>>>>> >
>>>>> > aversion to SOAP/WSDL -- yes, they work, but they are (IMO) also
>>>>> >
>>>>> > rather clumsy to develop with. Apologies for being so judgmental
>>>>> >
>>>>> > about those -- I'm sure they will work fine for any developer who
>>>>> >
>>>>> > is more comfortable with them than I am. I am very interested in
>>>>> >
>>>>> > building an architecture for communications between CAX tools and
>>>>> >
>>>>> > services, but I currently plan to use lightweight message-based
>>>>> >
>>>>> > technologies to implement a common "info bus" through which tools
>>>>> >
>>>>> > and services would communicate using a set of pub/sub type APIs.
>>>>> >
>>>>> > Of course, there may also be use cases for which remote object
>>>>> >
>>>>> > protocols are appropriate, but a lot of tools and services will
>>>>> >
>>>>> > require wrappers to participate and I suspect messsaging wrappers
>>>>> >
>>>>> > may be easier to write than remote-object-style wrappers that
>>>>> >
>>>>> > have to maintain a lot of state. That certainly doesn't preclude
>>>>> >
>>>>> > defining objects as the things that are communicating, so perhaps
>>>>> >
>>>>> > it's just a remote object architecture by another name. ;) The
>>>>> >
>>>>> > particular technology that I'm planning to experiment with is
>>>>> >
>>>>> > Twisted's "Asynchronous Messaging Protocol", AMP[1], which is
>>>>> >
>>>>> > very lightweight and elegant (Twisted also has Perspective
>>>>> >
>>>>> > Broker[2], an interesting remote object protocol).
>>>>> >
>>>>> >
>>>>> >
>>>>> >
>>>>> > * from a semantic viewpoint, whereas the computational model is
>>>>> explicit,
>>>>> >
>>>>> > the informational model is mostly implicit. For instance, the
>>>>> >
>>>>> > CadBrep::Face class definition could be whatever. In my opinion,
>>>>> > it
>>>>> could
>>>>> >
>>>>> > be a good thing to harmonize the semantics contained in the OCS
>>>>> > and
>>>>> the
>>>>> >
>>>>> > STEP parts 42, 55 etc.;
>>>>> >
>>>>> >
>>>>> >
>>>>> >
>>>>> > I wholeheartedly agree with that! In fact, speaking of
>>>>> >
>>>>> > semantics, I'd actually like to have an ontology (OWL) from which
>>>>> >
>>>>> > the informational model (schema) is generated -- of course, this
>>>>> >
>>>>> > is a design principle I'm trying to implement in my
>>>>> >
>>>>> > work-in-progress, PGEF[3] ... ;)
>>>>> >
>>>>> >
>>>>> >
>>>>> >
>>>>> > * some of the methods defined in OCS are strongly platform
>>>>> dependent: for
>>>>> >
>>>>> > instance CAD User Interface, paths etc. A high level CAD API
>>>>> > should
>>>>> >
>>>>> > abstract these concepts and be platform/CAD system independent;
>>>>> >
>>>>> >
>>>>> >
>>>>> >
>>>>> > I certainly agree that all methods should be platform
>>>>> >
>>>>> > independent. In a quick glance I didn't notice anything
>>>>> >
>>>>> > platform-dependent -- can you give an example?
>>>>> >
>>>>> >
>>>>> >
>>>>> >
>>>>> > * at last, I have a few doubts about the persistent identification
>>>>> since I
>>>>> >
>>>>> > know it's still considered as a major issue. And I wonder whether
>>>>> or not
>>>>> >
>>>>> > the OCC topological naming could be mapped to these
>>>>> > persistent_ids.
>>>>> >
>>>>> >
>>>>> >
>>>>> >
>>>>> > I agree there could be issues there also -- a big stumbling block
>>>>> >
>>>>> > in trying to implement a product model in which important printed
>>>>> >
>>>>> > circuit board features could have their identities survive a
>>>>> >
>>>>> > round-trip (import/export) to/from an MCAD tool is the lack of
>>>>> >
>>>>> > session-independent persistent identifiers in MCAD tools at the
>>>>> >
>>>>> > "feature" level. Of course, you might have meant something else
>>>>> >
>>>>> > ;), but that is one persistence issue I'm aware of!
>>>>> >
>>>>> >
>>>>> >
>>>>> > For me this is a very useful thread and I'd like to help in any
>>>>> >
>>>>> > way I can with helping to define and test a high-level CAD API.
>>>>> >
>>>>> >
>>>>> >
>>>>> > Cheers,
>>>>> >
>>>>> > Steve
>>>>> >
>>>>> >
>>>>> >
>>>>> > [1]
>>>>> http://twistedmatrix.com/documents/8.1.0/api/twisted.protocols.amp.html
>>>>> >
>>>>> > [2] http://twistedmatrix.com/documents/current/core/howto/pb.html
>>>>> >
>>>>> > [3] https://pangalactic.us/repo/pgef
>>>>> >
>>>>> >
>>>>> >
>>>>> > P.S. Thomas, do you think someone from the pythonOCC team might
>>>>> >
>>>>> > participate in PDE 2011? I hope so!
>>>>> >
>>>>> >
>>>>> >
>>>>> >
>>>>> > Best Regards,
>>>>> >
>>>>> >
>>>>> >
>>>>> > Thomas
>>>>> >
>>>>> > 2010/12/12 Stephen Waterbury water...@pangalactic.us
>>>>> water...@pangalactic.us>>
>>>>>
>>>>> >
>>>>> >
>>>>> >
>>>>> > Thomas, Dan, Dave,
>>>>> >
>>>>> >
>>>>> >
>>>>> > A precedent (or at least a closely related concept) was the "CAD
>>>>> >
>>>>> > Services API" developed by the [now defunct] OMG Manufacturing
>>>>> >
>>>>> > Technology & Industrial Systems Task Force (MANTIS). That
>>>>> >
>>>>> > specification is no longer active. It basically fell prey to
>>>>> >
>>>>> > the OMG rule that an active spec must be implemented by at least
>>>>> >
>>>>> > 2 vendors -- it was only implemented by one vendor (see below) --
>>>>> >
>>>>> > but it represents some good work that is still potentially
>>>>> >
>>>>> > useful.
>>>>> >
>>>>> >
>>>>> >
>>>>> > The fact that only ITI had a product that implemented the CAD
>>>>> >
>>>>> > Services API specification is more an indication of the hesitancy
>>>>> >
>>>>> > of CAD vendors to provide a standardized API than of the quality
>>>>> >
>>>>> > of the spec, IMO. ;) I've put a copy of its last version on my
>>>>> >
>>>>> > web server for convenience (not publicized since I think OMG's
>>>>> >
>>>>> > copyright might still be in force, not sure -- but since NASA
>>>>> >
>>>>> > contributed to the spec, I feel somewhat justified in making it
>>>>> >
>>>>> > available!):
>>>>> >
>>>>> >
>>>>> >
>>>>> > http://pangalactic.us/cax/CAD_Service_V1.1_030363.pdf
>>>>> >
>>>>> >
>>>>> >
>>>>> > It's interesting to note that both NASA *and* OpenCascade
>>>>> >
>>>>> > contributed to the spec. It is based on the API of "CADScript",
>>>>> >
>>>>> > a set of Python wrappers for CAD tools that was developed as a
>>>>> >
>>>>> > commercial product by Doug Cheney of International Technegroup
>>>>> >
>>>>> > Incorporated (ITI). CADScript is no longer offered by ITI as a
>>>>> >
>>>>> > product, but Doug (who is a strong python advocate) has used a
>>>>> >
>>>>> > Python API internally for another ITI product of which he is the
>>>>> >
>>>>> > primary developer, called CADIQ, which analyses CAD models for
>>>>> >
>>>>> > various types of modeling errors that could lead to data exchange
>>>>> >
>>>>> > problems or manufacturing problems, for example. (The CADIQ url
>>>>> >
>>>>> > is: http://www.transcendata.com/products/cadiq/) Doug presented
>>>>> >
>>>>> > the CADScript product at the PDE 2001 Workshop at JPL. His
>>>>> >
>>>>> > presentationslides are here:
>>>>> >
>>>>> >
>>>>> >
>>>>> >
>>>>> http://step.nasa.gov/pde2001/STEP-and-Scriptable-CAx-Tool-Integration_Doug-Cheney.ppt
>>>>> >
>>>>> >
>>>>> >
>>>>> > Doug also did an impressive live demo using CADScript for the
>>>>> >
>>>>> > Multi-CAD Assembly use case shown in his next-to-last slide.
>>>>> >
>>>>> > Also, from recent conversations with Doug, I know that users of
>>>>> >
>>>>> > the current CADIQ product can be given access to the supported
>>>>> >
>>>>> > Python API that it uses (not sure how much of CADScript might be
>>>>> >
>>>>> > there).
>>>>> >
>>>>> >
>>>>> >
>>>>> > I agree with what Thomas proposes below -- the concept of a
>>>>> >
>>>>> > standardized high-level API that would have a standardized
>>>>> >
>>>>> > framework or methods to specialize it for particular use cases.
>>>>> >
>>>>> > I'd suggest considering the CAD Services API specification as a
>>>>> >
>>>>> > starting point for a high-level API, since that spec incorporates
>>>>> >
>>>>> > a substantial amount of harmonization work that was done to
>>>>> >
>>>>> > develop a consensus high-level CAD API, and I think if pythonOCC
>>>>> >
>>>>> > provided a high-level API that implements even something close to
>>>>> >
>>>>> > the CAD Services API, it could provide a de facto industry
>>>>> >
>>>>> > standard high-level CAD API, with the hope of getting it adopted
>>>>> >
>>>>> > by other tools, and in the future possibly made a formal standard
>>>>> >
>>>>> > (by OMG, ISO/IEC, or whomever).
>>>>> >
>>>>> >
>>>>> >
>>>>> > Cheers,
>>>>> >
>>>>> > Steve
>>>>> >
>>>>> >
>>>>> >
>>>>> >
>>>>> >
>>>>> > On 12/11/2010 03:47 PM, Thomas Paviot wrote:
>>>>> >
>>>>> >
>>>>> >
>>>>> > Dear Dan, Dave,
>>>>> >
>>>>> >
>>>>> >
>>>>> > I didn't know about the openscad project, thanks for
>>>>> introducing me this
>>>>> >
>>>>> > project. Dave, you write "it is a tool that allows
>>>>> programmatically building
>>>>> >
>>>>> > solids using python and a CSG kernel", but I don't see any
>>>>> python scripting, I
>>>>> >
>>>>> > have rather the feeling that the scripting language of
>>>>> > openscad
>>>>> is a kind of
>>>>> >
>>>>> > specific language, am I wrong?
>>>>> >
>>>>> >
>>>>> >
>>>>> > I agree with both of you regarding the high-level API that
>>>>> could be built upon
>>>>> >
>>>>> > pythonOCC. Abstracting the low-level OCC api/data model would
>>>>> be something
>>>>> >
>>>>> > really helpful. From a development viewpoint, there is not big
>>>>> issue : we all
>>>>> >
>>>>> > developed or our own classes/methods or function in pythonOCC
>>>>> in ordre to
>>>>> >
>>>>> > speed up development and make our programs modular. The big
>>>>> deal is rather :
>>>>> >
>>>>> > what classes/methods should be made available to the user? How
>>>>> could this set
>>>>> >
>>>>> > of functions be complete, i.e. how to ensure that *all* the
>>>>> needs from any
>>>>> >
>>>>> > user are covered by this API ?
>>>>> >
>>>>> >
>>>>> >
>>>>> > In my opinion, there's no way to get it done (I've been
>>>>> thinking about this
>>>>> >
>>>>> > for a long time). We'll always find a user that is not
>>>>> satisfied with the API
>>>>> >
>>>>> > and who requests for another method/class etc. The risk is
>>>>> > then
>>>>> that this high
>>>>> >
>>>>> > level API become as big and complex as the original one (OCC).
>>>>> >
>>>>> >
>>>>> >
>>>>> > We could then imagine a different workflow than the usual one.
>>>>> I think about
>>>>> >
>>>>> > something that was used for the standardization of the AP239
>>>>> > of
>>>>> the STEP
>>>>> >
>>>>> > standard (also known as PCLS) : a very generic data model were
>>>>> designed (and
>>>>> >
>>>>> > standardized), and the specialization of the data model was
>>>>> also standardized.
>>>>> >
>>>>> > As a consequence, users with very specific business just join
>>>>> their efforts to
>>>>> >
>>>>> > define a standardized specialization of the generic data model
>>>>> suitable for
>>>>> >
>>>>> > their needs (aviation maintenance, operational feedback etc.).
>>>>> >
>>>>> >
>>>>> >
>>>>> > This development model could be moved to the pythonOCC high
>>>>> level API
>>>>> >
>>>>> > development :
>>>>> >
>>>>> >
>>>>> >
>>>>> > * a generic data model would be defined, with basic and
>>>>> fundamental
>>>>> >
>>>>> > elements ;
>>>>> >
>>>>> > * a framework for specializing this model is also defined.
>>>>> Both of this
>>>>> >
>>>>> > two points could be viewed at an ontological level ;
>>>>> >
>>>>> > * we then set up a 'high level API' repository with a set
>>>>> of basic
>>>>> >
>>>>> > classes/methods already defined ;
>>>>> >
>>>>> > * from these 2 points, we just let the user contribute new
>>>>> >
>>>>> > classes/functions/methods if what he is looking for is not
>>>>> already
>>>>> >
>>>>> > available from the repository.
>>>>> >
>>>>> >
>>>>> >
>>>>> > It could be a way for us (developpers of pythonocc) to share
>>>>> the development
>>>>> >
>>>>> > efforts of this needed high level API. And to have, as a
>>>>> consequence, a huge
>>>>> >
>>>>> > web-based repository of python classes/methods/functions,
>>>>> classified by
>>>>> >
>>>>> > businesses (FEM, manufacturing etc.), level of granularity,
>>>>> functions (gears,
>>>>> >
>>>>> > bearings etc.) etc.
>>>>> >
>>>>> >
>>>>> >
>>>>> > pythonOCC would then become a kind of distributed library : a
>>>>> core component
>>>>> >
>>>>> > (the python wrapper), required, and thousands of optional
>>>>> components available
>>>>> >
>>>>> > online, supported by a powerfull request engine. Setting up
>>>>> such an
>>>>> >
>>>>> > architecture is more a scientific project than a simple python
>>>>> development
>>>>> >
>>>>> > activity.
>>>>> >
>>>>> >
>>>>> >
>>>>> > What do you think about that idea?
>>>>> >
>>>>> >
>>>>> >
>>>>> > Thomas
>>>>> >
>>>>> >
>>>>> >
>>>>> > 2010/12/11 Dave Cowden dave.cow...@gmail.com
>>>>> dave.cow...@gmail.com> dave.cow...@gmail.com dave.cow...@gmail.com>>>
>>>>>
>>>>> >
>>>>> >
>>>>> >
>>>>> >
>>>>> >
>>>>> > Yes, definitely a higher level of abstraction is needed
>>>>> than just pure python.
>>>>> >
>>>>> >
>>>>> >
>>>>> > I am thinking ( not surprisingly ) of an environment a lot
>>>>> like a java
>>>>> >
>>>>> > ide. You write code, but the ide provides syntax
>>>>> highlighting,
>>>>> >
>>>>> > function completion, refactor support, code templates, a
>>>>> way to
>>>>> >
>>>>> > include other libraries, etc.
>>>>> >
>>>>> >
>>>>> >
>>>>> > On 12/10/10, Dan Falck dfa...@frontier.com
>>>>> dfa...@frontier.com> dfa...@frontier.com dfa...@frontier.com>>> wrote:
>>>>> >
>>>>> > > Yes, this technique does work- I've used it for
>>>>> > commercial
>>>>> design work
>>>>> >
>>>>> > > with some proprietary modelers (Ashlar Cobalt and PunchCad
>>>>> Shark FX)
>>>>> >
>>>>> > > that used a crude scripting language-called of all things
>>>>> 'Macro
>>>>> >
>>>>> > > Parser'. I was able to make simple changes to the scripting
>>>>> that would
>>>>> >
>>>>> > > be major changes to the model. This allowed for very
>>>>> flexible revisions.
>>>>> >
>>>>> > > It also made it easy to recover from a crash if the
>>>>> application was
>>>>> >
>>>>> > > acting finicky.
>>>>> >
>>>>> > > I was able to do fork crowns for bicycles (classic Italian
>>>>> style-not the
>>>>> >
>>>>> > > modern stuff) by using techniques that emulated a cnc mill
>>>>> tool path
>>>>> >
>>>>> > > through the solid block. The whole time I was working the
>>>>> model as a
>>>>> >
>>>>> > > machinist would at a mill or lathe- subtracting shapes from
>>>>> the solid
>>>>> >
>>>>> > > that I started with. Python code was necessary to keep me
>>>>> from losing my
>>>>> >
>>>>> > > mind during these projects :) I created some functions that
>>>>> made dealing
>>>>> >
>>>>> > > with the crude 'Macro Parser' scripting a lot easier.
>>>>> >
>>>>> > > PythonOCC looks a whole lot more attractive to me than my
>>>>> old work with
>>>>> >
>>>>> > > this crude scripting. But, I would like to be able to
>>>>> abstract it a
>>>>> >
>>>>> > > little more though to make it easier to remember how to use
>>>>> it, without
>>>>> >
>>>>> > > having to go to the OCC docs all the time. I would bet that
>>>>> Thomas and
>>>>> >
>>>>> > > Jelle are working on something like this.
>>>>> >
>>>>> > > I think this project might be similar to what we are
>>>>> > talking
>>>>> about:
>>>>> >
>>>>> > >
>>>>> >
>>>>> > > http://www.caddd.org/
>>>>> >
>>>>> > >
>>>>> >
>>>>> > > Dan
>>>>> >
>>>>> > >
>>>>> >
>>>>> > > On 12/10/10 2:27 PM, Dave Cowden wrote:
>>>>> >
>>>>> > >> I assume that someone has seen this:
>>>>> >
>>>>> > >>
>>>>> >
>>>>> > >> http://openscad.org/
>>>>> >
>>>>> > >>
>>>>> >
>>>>> > >> it is a tool that allows programmatically building solids
>>>>> using python
>>>>> >
>>>>> > >> and a CSG kernel.
>>>>> >
>>>>> > >>
>>>>> >
>>>>> > >> If such a tool used pythonOCC instead, it would be _much_
>>>>> more powerful.
>>>>> >
>>>>> > >>
>>>>> >
>>>>> > >> This kind of tool is really interesting to me. Anyone who
>>>>> has done
>>>>> >
>>>>> > >> much solid modelling for a living quickly realizes that a
>>>>> complex
>>>>> >
>>>>> > >> solid model is much like a programming problem. You
>>>>> > cannot
>>>>> just
>>>>> >
>>>>> > >> 'start building' a complex model: you have to plan how the
>>>>> object is
>>>>> >
>>>>> > >> built, which references are used, etc, so that the object
>>>>> is
>>>>> >
>>>>> > >> extensible and easily changed to accommodate design
>>>>> iterations. It
>>>>> >
>>>>> > >> becomes really important to plan reference planes and
>>>>> > other
>>>>> reference
>>>>> >
>>>>> > >> geometries to reference each other in a way consistent
>>>>> > with
>>>>> the rest
>>>>> >
>>>>> > >> of the model.
>>>>> >
>>>>> > >>
>>>>> >
>>>>> > >> Using a programming language to capture the [currently
>>>>> always
>>>>> >
>>>>> > >> proprietary] way that solid modelling packages capture the
>>>>> build order
>>>>> >
>>>>> > >> and dependency chains of a solid ( especially parametric
>>>>> solids ) is
>>>>> >
>>>>> > >> brilliant. As programmers, we are very familiar with the
>>>>> ability to
>>>>> >
>>>>> > >> use CVS merge and other utilities to track fine-grained
>>>>> changes to
>>>>> >
>>>>> > >> software over time, even when under concurrent
>>>>> > development.
>>>>> Imagine
>>>>> >
>>>>> > >> the power of this capability applied to scripts that
>>>>> produce solid
>>>>> >
>>>>> > >> objects! No more huge binary solid object files that are
>>>>> opaque from
>>>>> >
>>>>> > >> a change management viewpoint!
>>>>> >
>>>>> > >>
>>>>> >
>>>>> > >> Does anyone know if such a package is underway anywhere
>>>>> based on
>>>>> >
>>>>> > >> pythonOCC?
>>>>> >
>>>>> > >>
>>>>> >
>>>>> > >>
>>>>> >
>>>>> > >>
>>>>> >
>>>>> > >> _______________________________________________
>>>>> >
>>>>> > >> Pythonocc-users mailing list
>>>>> >
>>>>> > >> Pythonocc-users@gna.org Pythonocc-users@gna.org>
>>>>> Pythonocc-users@gna.org Pythonocc-users@gna.org>>
>>>>>
>>>>> >
>>>>> >
>>>>> >
>>>>> > >> https://mail.gna.org/listinfo/pythonocc-users
>>>>> >
>>>>> > >
>>>>> >
>>>>> >
>>>>> >
>>>>> > --
>>>>> >
>>>>> > Sent from my mobile device
>>>>> >
>>>>> >
>>>>> >
>>>>> > _______________________________________________
>>>>> >
>>>>> > Pythonocc-users mailing list
>>>>> >
>>>>> > Pythonocc-users@gna.org Pythonocc-users@gna.org>
>>>>> Pythonocc-users@gna.org Pythonocc-users@gna.org>>
>>>>>
>>>>> >
>>>>> >
>>>>> >
>>>>> > https://mail.gna.org/listinfo/pythonocc-users
>>>>> >
>>>>> >
>>>>> >
>>>>> >
>>>>> >
>>>>> >
>>>>> >
>>>>> >
>>>>> >
>>>>> > _______________________________________________
>>>>> >
>>>>> > Pythonocc-users mailing list
>>>>> >
>>>>> > Pythonocc-users@gna.org Pythonocc-users@gna.org>
>>>>>
>>>>> >
>>>>> > https://mail.gna.org/listinfo/pythonocc-users
>>>>> >
>>>>> >
>>>>> >
>>>>> >
>>>>> >
>>>>> >
>>>>> >
>>>>> > _______________________________________________
>>>>> >
>>>>> > Pythonocc-users mailing list
>>>>> >
>>>>> > Pythonocc-users@gna.org Pythonocc-users@gna.org>
>>>>>
>>>>> >
>>>>> > https://mail.gna.org/listinfo/pythonocc-users
>>>>> >
>>>>> >
>>>>> >
>>>>> >
>>>>> >
>>>>> >
>>>>> >
>>>>> >
>>>>> >
>>>>> > _______________________________________________
>>>>> >
>>>>> > Pythonocc-users mailing list
>>>>> >
>>>>> > Pythonocc-users@gna.org
>>>>> >
>>>>> > https://mail.gna.org/listinfo/pythonocc-users
>>>>> >
>>>>> >
>>>>> >
>>>>> >
>>>>> >
>>>>> >
>>>>> > _______________________________________________
>>>>> >
>>>>> > Pythonocc-users mailing list
>>>>> >
>>>>> > Pythonocc-users@gna.org
>>>>> >
>>>>> > https://mail.gna.org/listinfo/pythonocc-users
>>>>> >
>>>>>
>>>>> _______________________________________________
>>>>> Pythonocc-users mailing list
>>>>> Pythonocc-users@gna.org
>>>>> https://mail.gna.org/listinfo/pythonocc-users
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> Pythonocc-users mailing list
>>>> Pythonocc-users@gna.org
>>>> https://mail.gna.org/listinfo/pythonocc-users
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Pythonocc-users mailing list
>>> Pythonocc-users@gna.org
>>> https://mail.gna.org/listinfo/pythonocc-users
>>>
>>>
>>
>> _______________________________________________
>> Pythonocc-users mailing list
>> Pythonocc-users@gna.org
>> https://mail.gna.org/listinfo/pythonocc-users
>>
>>
>
--
Sent from my mobile device
_______________________________________________
Pythonocc-users mailing list
Pythonocc-users@gna.org
https://mail.gna.org/listinfo/pythonocc-users
