adp:

Thank you for taking the time to explain how to write the server, but as I've said, I already implemented a server and had no trouble with that. What I wrote is sort of like a Java servlet engine, but the servlets are written in Python. I call it PASer (Poser Application Server). I have already written a dozen servlets for various purposes. The most used one is a light panel that puts together a nice web page GUI to control all the light parameters and shadow settings. I know how to do network I/O in a non-blocking way, and how to write client/server software, or browser/appserver software. I do all these things for a living.

What I was asking about was the blocking aspect of your service loop.

Earlier you wrote:

"In my version IPC works in "non-blocking" mode. Means, IPC-communication works in background (with all Poser versions >= 5). Even other Python scripts may be started as usual without breaking IPC."

but then later you wrote:

"As soon as my script is called the first time, it enters an endless "blocking-loop"."

That is the contradiction and the specific issue I'm struggling with. As I wrote earlier, I tried several techniques for getting control and servicing my browser requests. The only one that worked well is the blocking-loop, precisely what you showed in your last post.

But that is very much NOT going to let other Python scripts be started by Poser. Poser (rightly) believes that my main Paser script is still running, and refuses to launch any other Python scripts. Users will find this not very friendly and will get confused. In fact, I've seen this confusion recently. Look at this thread:

http://www.renderosity.com/mod/forumpro/showthread.php?message_id=3263103

Mathman was complaining that a wacro didn't do anything for him. It took him quite a while to realize it had nothing to do with the wacro. The problem was he had a PRPC daemon running and had forgotten about it. The PRPC daemon uses the same "blocking" loop strategy, which prevents Poser from running any other scripts. When you push a script button or menu item, Poser doesn't tell you why it is refusing - it simply doesn't do anything.

One solution I had to this was to add the ability to run scripts from within Paser. This means the user can still run scripts - but cannot run them from the Poser GUI. They must be invoked from the Paser script browser pages. This is OK I guess. But consider this:

Suppose the user is already running Paser, which is uses a blocking loop as above. Now this user runs YOUR server daemon, which goes into its own blocking loop. My loop is now halted, until your loop exits!

This would be a terribly complicated and confusing situation. The user will not understand why Paser pages (serviced by my loop) stop working while your server is running.

This is the reason I asked you how the heck you made it non-blocking. But then your answer was that you actually made it blocking. I'm not following that.

What we really should do is establish a standard, whereby we all share a common service loop that we agree to install and run exactly once. Then all of us write our little background activities and servlets under the assumption that we can all share the same blocking loop.

---

Renderosity forum reply notifications are wonky. If I read a follow-up in a thread, but I don't myself reply, then notifications no longer happen AT ALL on that thread. So if I seem to be ignoring a question, that's why. (Updated September 23, 2019)