I agree with you -- it's hard to safely kill a runaway thread but it's not hard to kill a runaway process. But I think it's worth noting that the performance characteristics of IPC can be very bad
I appreciate your feedback and I totally want to market it in the way you propose. But let me be real: I am one person doing everything. I expect to have all that stuff by September when I plan to launch 1.0. If I were "in control" of this situation, I'd prefer the app get more buzz closer to launch rather than 6 months away. But I can't really control when people post to hacker news... And in any case I think all publicity is good. Dying in obscurity is the biggest risk.
When I get to version 1.0 I will do all of those things. For now this is a beta, more for artists who are interested offering feedback to affect the design of the app.
I think it's fine for people to have varying philosophical takes on what should be the normative goals of open source software licenses. Obviously the FSF takes a rather maximalist stance. I personally find this aggressive goal and some of the personalities behind it to not match my vibe. And the reality is that more permissive licenses like MIT are becoming more and more popular.
What I've seen some Blender plugins do to get around this is to have an open-source plugin communicate via IPC to a closed source library. It's totally legal. It's a performance and implementation tax that just seems silly to me.
It is for sure a murky area where I'm working out the details. You don't have the full kernel. But you can think of it a bit like a scripting API on top of the kernel, which is not uncommon in CAD apps, like OnShape's FeatureScript or something.
> So external contributors can only provide patches without being able to test themselves I suppose.
My intention is that if you buy a license for plasticity, you can then build locally and test locally. You can contribute back or not depending on your interest.
Think of it like this. There will be a typescript/javascript wrapper around a limited version of the c3d kernel. this is the plasticity api. You will call plasticity.Enable(license_key) at the top of your program and you will be good to go. You buy a license key from me.
Although I do hope people will contribute the plasticity's development, my main goal with it being open source is that people will write plugins that they can then give away or sell themselves.
I have used commercial software that I pay for -- like Fusion 360 and MoI3d -- where I ran into bugs that I could have fixed for myself if only I had the code. I'm still happy to pay for them. Instead I literally waited 2 years for Fusion to fix a bug I cared about.
That’s exactly my take. What exactly constitutes a “derived work” in the gpl (plug-ins do!) is counter intuitive to me.
Even the lgpl definition of “dynamic linking” is something that scares me in the context of npm modules, which is why I’m nervous I made the wrong choice with lgpl
I thought I am the copyright owner and I can offer my code under as many licenses as I want. Many people dual license gpl code is my understanding. Converting my own code to mit should be allowed right?
Every Google result I’ve found says I’m the copyright owner and I can offer as many licenses as I want. Are you just trolling?
I will say I’m constantly bewildered by which license to choose. I’m using copyleft to defend myself a bit. But weak copyleft because I’ve hate that the gpl prevents blender plug-ins from being closed source or linking against something closed source. Plasticity will allow plug-ins to do whatever they want, that’s the goal.
There is some possibility I will switch to MIT since philosophically I’m more in that camp
Parasolid and Acis are the only other options. I have a lot of admiration for OpenCascade but unfortunately its functionality is very limited for my needs.
I’m considering parasolid but, no, I can’t keep this price point with it
I think the main thing to understand is that blender has minimal nurbs support. For example, try doing booleans, fillets, or offset surfaces with blender nurbs. You can’t.
Nurbs are good for some shapes and bad for others. In addition to manufacturing, nurbs are great for hard surface / scifi assets for video games and movies.
Plasticity is for artists. It is more in the tradition of MoI3d than say solidworks. It has a very powerful geometry kernel and the user interface is meant to be familiar to blender users and modern looking.
I want to emphasize to everyone that this is for concept artists. It’s nurbs used to create interesting shapes and fillets. While there are some parametric features, they’re completely de emphasized compared to something like fusion or solidworks
This is a significant issue for anyone doing business with Russia. I’m happy with c3d in general but there is a possibility I will be forced to use another kernel
A full build from scratch would require the c3d headers, which I can’t provide.
What I am planning is to something like this: divide the app into two pieces, an npm wrapper around the kernel and the electron front end that uses the module.
You will need a license key to “activate” the node module. You would then use the electron app or the module directly if you’re a programmer. You will be able to build your own fork of the electron app, but not the npm module.
In effect you will be paying for a license key, not the binary
I wonder if you could handle backpressure this way, somewhat analogously to a thread-per-connection with a bounded number of threads. I don't think node.js API exposes the necessary functionality, but the point is that it's possible with callbacks:
var MAX = 100,
connections = 0;
function continue() {
server.once('connection', function(c) {
if (++connections < MAX) continue();
process(c, function() {
if (--connections == MAX - 1) continue();
});
});
}
continue();
Node.js doesn't have threads so you wouldn't need atomics or locking. I don't think it's fair to say this is spaghetti, but it has some complexity, yes.