2010/12/13 Stephen Waterbury <water...@pangalactic.us> > 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.
Well, I use to work with suds (https://fedorahosted.org/suds/) which is a very convenient way to work with web services under python. The boring stuff (parsing/generating WSDL files for instance) is completely abstracted. > 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). > Thanks for the links, it seems very interesting. I thank both Dave and you for the information about messages. I think it can make the exchange and sharing of business objects or API more dynamic than something based upon WSDL/SOAP (a spec based on one or more WSDL files is unreadable for a human-I mean, a normal human being without any superhero extra ability- and, at the same time, is a kind of closed, rigid, hardly extensible API). To me, the easiest way to call the distant function create_point(10.,10,10.) is to send the string "CALL_FUNCTION, create_point, (10,10,10)" to the server. The same thing using SOAP would required a 100 lines long WSDL file as well as the exchange of a 10 lines XML formatted message (maybe it's a bit exaggerated). > > * 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? > Well, the 'platform' dependency was not the right word, sorry, if we think 'platform' as Windows/Linux/MacOS etc. I rather thought about the 'architecture' dependency. Take for instance the 'create_new_folder' or 'get_root_directories' functions. They are the consequence of the asumption that the models are stored in files, on a hard drive. It can seem quite outdated regarding current networked architectures. In my opinion, such functions have nothing to do with a high level CAD API. They can be abstracted at a higher level (semantics) with for instance 'categories' or 'ressource identifier', 'ressource location' etc. The second OMG CAD Services asumption is that the CAD softwares necessarily come with a GUI (see the 'get_gui' function). I'm not sure about that. I'd like the pythonOCC high level API be independent from any GUI (pythonOCC itself doesn't provide any GUI but a poor 3D rendering window). > * 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! > That's the one I had in mind. > > 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. > It could be a good thing if we can join our efforts. What about a page dedicated to this project on the pythonOCC wiki? Maybe it could be a good solution to let anyone give his opinion and have a synthesis of our current mail exchanges. > > Cheers, > Steve > Do you know where and when the PDE 2011 conference will take place? Cheers, Thomas > > [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 <mailto: >> 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 <mailto: >> dave.cow...@gmail.com> <mailto:dave.cow...@gmail.com <mailto: >> 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 <mailto: >> dfa...@frontier.com> <mailto:dfa...@frontier.com <mailto: >> 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 <mailto:Pythonocc-users@gna.org> >> <mailto:Pythonocc-users@gna.org <mailto:Pythonocc-users@gna.org>> >> >> >> >> https://mail.gna.org/listinfo/pythonocc-users >> > >> >> -- >> Sent from my mobile device >> >> _______________________________________________ >> Pythonocc-users mailing list >> Pythonocc-users@gna.org <mailto:Pythonocc-users@gna.org> <mailto: >> Pythonocc-users@gna.org <mailto:Pythonocc-users@gna.org>> >> >> >> https://mail.gna.org/listinfo/pythonocc-users >> >> >> >> >> _______________________________________________ >> Pythonocc-users mailing list >> Pythonocc-users@gna.org <mailto:Pythonocc-users@gna.org> >> https://mail.gna.org/listinfo/pythonocc-users >> >> >> >> _______________________________________________ >> Pythonocc-users mailing list >> Pythonocc-users@gna.org <mailto: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
