Hi, Steve:
I'm definitely in agreement with you about CORBA/SOAP. I'ma 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
PS 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, ie 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
