Nabble has removed Mailing-list integration.
Posts created here DO NOT GET SENT TO THE MAILING LIST.
Mailing-list emails DO NOT GET POSTED TO THE FORUM.
So basically the Forum is now out of date, we are looking into migrating the history.

For now you should send emails, people will see them, discuss@lists.openscad.org.

Re: [Pythonocc-users] Scripting without visualization

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

Re: [Pythonocc-users] Scripting without visualization

Bryan Bishop
On Wed, Feb 10, 2010 at 1:42 PM, Thomas Paviot wrote:
> It's completely possible to implement your idea. Actually, if you already
> have good skills in Django, it's something you can achieve within only a few
> hours. For someone with good Django/pythonOCC skills, it's not more than two
> hours to have something running and a material ready to convince your boss.

I made something like this with the cherrypy web framework. I was
really excited because I thought I was making the first web framework
that imported a CAD geometry kernel. Maybe not :-).

http://designfiles.org/skdb/web/web.py

To see it in action:

http://designfiles.org:8081/package/lego/

Basically, it's an open source hardware repository built on top of
cherrypy and git repositories. Individual hardware projects are stored
in individual git repositories, exposed to the web. There's a built-in
ability to visualize and re-parameterize the objects, but it's not
fully implemented or exposed through the web interface yet.

> I'm not sure you have to use the parametric framework. You can simply
> develop a python function that takes the 3 parameters and write the STEP
> file. You can also have this function in a python script that is launched
> from a pipe whenever needed. You can also split the solution on two
> different servers : the webserver and the 'cadserver', with a proper data
> exchange model/protocol (with RPC/XML for instance). Well, all that stuff
> depend on your needs, but everything is possible.

Splitting it up into two parts is a good idea. For instance,
visualization in pythonOCC still requires an active X11 session, so
having that on a separate (virtualized) server is probably a good idea
for the time being. Otherwise the page loads would probably be too
long.

> To go further, I've been thinking for a while on a way to add a network
> layer to pythonOCC, over the OCC kernel. The XML/RPC sample was a first
> draft on how to exchange geometry, and I wish to go far beyond. We are about
> to launch a project untitled 'Network Enabled PythonOCC', and try to think
> about implementation of CAD Services/PLM Services/SOA/SaaS etc. It's a
> strategic necessity to enable pythonOCC being part of an heterogenous IT
> system (well, I confess interoperability issues in the PLM field are my
> guilty pleasure!).  The implementation part of this work will be supported
> by a university. I will explain the details of this project (and 2 other
> ones) when it is about to start, in less than a couple of weeks if
> everything goes fine.

Could you elaborate on the details?

- Bryan
http://heybryan.org/
1 512 203 0507