It would be nice to have the option to upgrade to a python3.x Version of Webware for later purpose.
Backward Compatiblity would be nice until python2.5 (python2.6 is buggy)
We currently don't use WSGI capability, we use WebKit at all.

Compatiblity should be given so, that API remains the same, but using python3.x
capability. This should be possible, I think. API changes would very bad at all.

I have seen it at the print-function in python3. To port thousands of such places is a real
overkill. This API-Change is really the worst of all. I simply can't understand why
the didn't wrote an enhanced function for this...

However we use many modules where still no python3 port is existing.
For now, switching to higher python version, would still not effective for us.

Best Regards


Am 19.09.2012 17:01, schrieb Christoph Zwerschke:
Am 17.09.2012 11:27, schrieb Sophana K:
I'm using webware 1.0, because webware 1.1 didn't work correctly for
me (I don't remember why)
You should definitely try 1.1 again. It works great for me and if there 
are any real issues, please report and I'll be glad to fix them.

I'm currently trying to debug a freeze problem that occur every 1 to
3 weeks.The python appServer process is completely frozen, and must
be killed with -9.It doesn't respond to any signal, so I can't dump
its stack, and really don't know the cause strace shows that python
is waiting on a futex.
Again, I don't think this is a problem with Webware itself. I have my 
Webware 1.1 apps running on many servers for months without restart.

I still have some actions to do in my investigations like:
- separating the custom radius server I made which is launched in the
same process in several new threads. (I didn't know about the GIL at
that time...)
This could really be the problem. You should run it in a separate process.

- reverting to webware 0.9
Don't do that. There have been many bugfixes and improvements in 1.x.

I've seen that there is a WSGI adapter that connects to the appServer.
Is it possible to wrap a webware application in a real WSGI handler?
This would allow to use webware applications under modern servers
like gevent (gunicorn) and why not google app engine. The threaded
app server is no more adapted to modern web techniques. A gevent
based appServer would be so great! libraries like gevent-zeromq and
gevent-socketio would be so nice to have.
Yes, the adapter needs a running appserver. This has also advantages, 
because it decouples your WSGI server from the application.

But you're right, it would be nice to have an option to run Webware 
applications without the AppServer, directly wrapped as WSGI, so we 
could make use of existing non-threaded WSGI servers. Actually, I 
discussed these ideas already years ago on this mailing list. However, 
there was not so much feedback and I had not enough time to realize it, 
so these ideas were not realized so far.

So my question to this mailing list would be: How many people are still 
interested in having a modernized Webware version? How backward 
compatible must it be? Would it be ok to change package and method names 
to make them comply with PEP8 or to change getter functions to 
properties or should it be as compatible as possible? Which plugins and 
functionality should still be supported, what can be stripped away 
(personally, I'm using only WebKit)?

-- Christoph

Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
Webware-discuss mailing list