Webware for Python

Hi!

I've been using the svn head on a test system for a while now without
any problem.  Would you object using svn head in a production
environment?

Thank you!
-- 
Bye, Andreas

Re: [Webware-discuss] Using SVN head in production environment From: Sophana K <sophana78@gm...> - 2012-12-06 09:56 Attachments: Message as HTML      Hi Looking at the svn logs, it looks like the changes are quite minor since the 1.1 release. I think most of them correspond to some bugs reported in this mailing list. On Thu, Dec 6, 2012 at 10:34 AM, Andreas Poisel <a.poisel@...> wrote: > Hi! > > I've been using the svn head on a test system for a while now without > any problem. Would you object using svn head in a production > environment? > > Thank you! > -- > Bye, Andreas > > > ------------------------------------------------------------------------------ > LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial > Remotely access PCs and mobile devices and provide instant support > Improve your efficiency, and focus on delivering more value-add services > Discover what IT Professionals Know. Rescue delivers > http://p.sf.net/sfu/logmein_12329d2d > _______________________________________________ > Webware-discuss mailing list > Webware-discuss@... > https://lists.sourceforge.net/lists/listinfo/webware-discuss >

Re: [Webware-discuss] Using SVN head in production environment From: Andreas Poisel <a.poisel@ac...> - 2012-12-06 10:17 * Sophana K <sophana78@...> [06.12.2012 11:00]: > Looking at the svn logs, it looks like the changes are quite minor since > the 1.1 release. > I think most of them correspond to some bugs reported in this mailing list. That's my impression, too. But I have no experience with ctypes and wanted to make sure the changes to the threading code (e.g. rev 8235) are considered stable. -- Bye, Andreas

Re: [Webware-discuss] Using SVN head in production environment From: Christoph Zwerschke <cito@on...> - 2012-12-06 11:02 Am 06.12.2012 10:34, schrieb Andreas Poisel: > I've been using the svn head on a test system for a while now without > any problem. Would you object using svn head in a production > environment? Yes, as Sophana already answered, the trunk is stable; I want to cut a new release from it this month anyway. r8235 fixes a problem with aborting long-running threads on 64bit platforms. You can use http://localhost:8080/Admin/ThreadControl to play with this feature and see if requests can be properly cancelled on your machine. -- Christoph

Hi

I just upgraded to webware-1.1, and get some errors (about every day) in
the session dynamic store intervalSweep method.

Here is the traceback
 File "/home/sophana/src/env1/Webware-1.1/WebKit/Tasks/SessionTask.py",
line 13, in run
    self._sessionstore.cleanStaleSessions(self)
  File "/home/sophana/src/env1/Webware-1.1/WebKit/SessionDynamicStore.py",
line 264, in cleanStaleSessions
    self.intervalSweep()
  File "/home/sophana/src/env1/Webware-1.1/WebKit/SessionDynamicStore.py",
line 288, in intervalSweep
    for key in self._memoryStore:
RuntimeError: dictionary changed size during iteration

Look like another thread could be changing the _memoryStore during this
iteration.
Should I change to
for key in list(self._memoryStore):
?

Regards
Sophana

Re: [Webware-discuss] RuntimeError: dictionary changed size during iteration From: Christoph Zwerschke <cito@on...> - 2012-11-28 11:56 Am 28.11.2012 12:10, schrieb Sophana K: > Look like another thread could be changing the _memoryStore during > this iteration. Should I change to > for key in list(self._memoryStore): Yes, this or "for key in self._memoryStore.keys()" should fix it. I have already committed this as a fix to the trunk. -- Chris

Re: [Webware-discuss] RuntimeError: dictionary changed size during iteration From: Sophana K <sophana78@gm...> - 2012-11-30 12:48 Attachments: Message as HTML      It seems the problem has now moved to another place. Should I try the trunk? File "/home/.../Webware-1.1/WebKit/Tasks/SessionTask.py", line 13, in run self._sessionstore.cleanStaleSessions(self) File "/home/.../Webware-1.1/WebKit/SessionDynamicStore.py", line 256, in cleanStaleSessions self._memoryStore.cleanStaleSessions(task) File "/home/.../Webware-1.1/WebKit/SessionStore.py", line 202, in cleanStaleSessions for key in self: RuntimeError: dictionary changed size during iteration On Wed, Nov 28, 2012 at 12:56 PM, Christoph Zwerschke <cito@...: > Am 28.11.2012 12:10, schrieb Sophana K: > > Look like another thread could be changing the _memoryStore during > > this iteration. Should I change to > > for key in list(self._memoryStore): > > Yes, this or "for key in self._memoryStore.keys()" should fix it. I have > already committed this as a fix to the trunk. > > -- Chris > > > ------------------------------------------------------------------------------ > Keep yourself connected to Go Parallel: > INSIGHTS What's next for parallel hardware, programming and related areas? > Interviews and blogs by thought leaders keep you ahead of the curve. > http://goparallel.sourceforge.net > _______________________________________________ > Webware-discuss mailing list > Webware-discuss@... > https://lists.sourceforge.net/lists/listinfo/webware-discuss >

Re: [Webware-discuss] RuntimeError: dictionary changed size during iteration From: Christoph Zwerschke <cito@on...> - 2012-11-30 16:36 Am 30.11.2012 13:48, schrieb Sophana K: > It seems the problem has now moved to another place. > Should I try the trunk? > > File "/home/.../Webware-1.1/WebKit/Tasks/SessionTask.py", line 13, in run > self._sessionstore.cleanStaleSessions(self) > File "/home/.../Webware-1.1/WebKit/SessionDynamicStore.py", line 256, in cleanStaleSessions > self._memoryStore.cleanStaleSessions(task) > File "/home/.../Webware-1.1/WebKit/SessionStore.py", line 202, in cleanStaleSessions > for key in self: > RuntimeError: dictionary changed size during iteration Same problem. It's now also fixed in the trunk. -- Christoph

Re: [Webware-discuss] RuntimeError: dictionary changed size during iteration From: Sophana K <sophana78@gm...> - 2012-11-30 17:01 Attachments: Message as HTML      Thanks Isn't it strange nobody had this problem before? Seems that there isn't a lot of webware 1.1 applications in production. Don't you think? Sophana On Fri, Nov 30, 2012 at 5:36 PM, Christoph Zwerschke <cito@...> wrote: > Am 30.11.2012 13:48, schrieb Sophana K: > > It seems the problem has now moved to another place. > > Should I try the trunk? > > > > File "/home/.../Webware-1.1/WebKit/Tasks/SessionTask.py", line 13, in > run > > self._sessionstore.cleanStaleSessions(self) > > File "/home/.../Webware-1.1/WebKit/SessionDynamicStore.py", line 256, > in cleanStaleSessions > > self._memoryStore.cleanStaleSessions(task) > > File "/home/.../Webware-1.1/WebKit/SessionStore.py", line 202, in > cleanStaleSessions > > for key in self: > > RuntimeError: dictionary changed size during iteration > > Same problem. It's now also fixed in the trunk. > > -- Christoph > > > > > > > > ------------------------------------------------------------------------------ > Keep yourself connected to Go Parallel: > TUNE You got it built. Now make it sing. Tune shows you how. > http://goparallel.sourceforge.net > _______________________________________________ > Webware-discuss mailing list > Webware-discuss@... > https://lists.sourceforge.net/lists/listinfo/webware-discuss >

Re: [Webware-discuss] RuntimeError: dictionary changed size during iteration From: NoRaGen <noragen@gm...> - 2012-11-30 17:16 Attachments: Message as HTML      Hi Sophana, hi Christoph, the webware for python is used in two companies, on 4 Servers, I work for. It is running very stable. But however we use a self-implemented session. Thats why it seems, I didn't mentioned this problem to Christoph. But our claims, we have to the session is a little bit bigger one that the one from webware has and it was easier to build an own, derived one. However, Webkit is pretty stable, there is no need not to take it, because Christoph very cares about all. Thank you Christoph btw. for all your help and support everytime so far! Best Regards, Tobias ------------------------------------------------------------------------ Am 30.11.2012 18:01, schrieb Sophana K: > Thanks > > Isn't it strange nobody had this problem before? > Seems that there isn't a lot of webware 1.1 applications in production. > Don't you think? > > Sophana > > > On Fri, Nov 30, 2012 at 5:36 PM, Christoph Zwerschke <cito@... > <mailto:cito@...>> wrote: > > Am 30.11.2012 13:48, schrieb Sophana K: > > It seems the problem has now moved to another place. > > Should I try the trunk? > > > > File "/home/.../Webware-1.1/WebKit/Tasks/SessionTask.py", line > 13, in run > > self._sessionstore.cleanStaleSessions(self) > > File "/home/.../Webware-1.1/WebKit/SessionDynamicStore.py", > line 256, in cleanStaleSessions > > self._memoryStore.cleanStaleSessions(task) > > File "/home/.../Webware-1.1/WebKit/SessionStore.py", line > 202, in cleanStaleSessions > > for key in self: > > RuntimeError: dictionary changed size during iteration > > Same problem. It's now also fixed in the trunk. > > -- Christoph > > > > > > > ------------------------------------------------------------------------------ > Keep yourself connected to Go Parallel: > TUNE You got it built. Now make it sing. Tune shows you how. > http://goparallel.sourceforge.net > _______________________________________________ > Webware-discuss mailing list > Webware-discuss@... > <mailto:Webware-discuss@...> > https://lists.sourceforge.net/lists/listinfo/webware-discuss > > > > > ------------------------------------------------------------------------------ > Keep yourself connected to Go Parallel: > TUNE You got it built. Now make it sing. Tune shows you how. > http://goparallel.sourceforge.net > > > _______________________________________________ > Webware-discuss mailing list > Webware-discuss@... > https://lists.sourceforge.net/lists/listinfo/webware-discuss

Re: [Webware-discuss] RuntimeError: dictionary changed size during iteration From: Christoph Zwerschke <cito@on...> - 2012-11-30 17:23 Am 30.11.2012 18:01, schrieb Sophana K: > Isn't it strange nobody had this problem before? > Seems that there isn't a lot of webware 1.1 applications in production. > Don't you think? T

Re: [Webware-discuss] RuntimeError: dictionary changed size during iteration From: Christoph Zwerschke <cito@on...> - 2012-11-30 17:28 Am 30.11.2012 18:01, schrieb Sophana K: > Isn't it strange nobody had this problem before? Seems that there > isn't a lot of webware 1.1 applications in production. Don't you > think? That problem should not appear in practice unless you have somehow two session sweeper tasks running at the same time. Are you doing anything special in this regard? I'm running Webware 1.1 apps with many users which use sessions heavily, and I've never seen this issue. -- Christoph (Sorry, my mailer just sent an empty reply.)

Re: [Webware-discuss] RuntimeError: dictionary changed size during iteration From: Sophana K <sophana78@gm...> - 2012-12-06 09:59 Attachments: Message as HTML      I have some tasks scheduled every 30m and 24h. I did nothing special about the session sweeper. Are they related to taskKit? On Fri, Nov 30, 2012 at 6:28 PM, Christoph Zwerschke <cito@...> wrote: > Am 30.11.2012 18:01, schrieb Sophana K: > > Isn't it strange nobody had this problem before? Seems that there > > isn't a lot of webware 1.1 applications in production. Don't you > > think? > > That problem should not appear in practice unless you have somehow two > session sweeper tasks running at the same time. Are you doing anything > special in this regard? I'm running Webware 1.1 apps with many users > which use sessions heavily, and I've never seen this issue. > > -- Christoph > > (Sorry, my mailer just sent an empty reply.) > > > ------------------------------------------------------------------------------ > Keep yourself connected to Go Parallel: > TUNE You got it built. Now make it sing. Tune shows you how. > http://goparallel.sourceforge.net > _______________________________________________ > Webware-discuss mailing list > Webware-discuss@... > https://lists.sourceforge.net/lists/listinfo/webware-discuss >

Hello!
First of all, thank you, Christoph, for the excellent software! I've been using webware since 2002 and have not yet seen a decent replacement to it! Outstanding performance of lightweight servlets implementation leaves behind its competitors with their tons of useless code. That's the main feature I'm using from webware.
Upgraded recently to 1.1 and discovered a freeze when I press Ctrl+C. It happens only on Windows. I'm using Windows 7. Linux is not affected.
In fact the reason of the freeze seems to be quite simple:
ThreadedAppServer.py, line 1308:
                    t = Thread(target=_windowsmainloop)
                    t.start()
...
_windowsmainloop calls server.mainloop(), which flags self._running:
        threadCheckInterval = self._maxServerThreads * 2
        threadUpdateDivisor = 5 # grab stat interval
        threadCheck = 0

--->  self._running = 3 # server is in the main loop now


On subsequent check server._running is still 1 because the thread does not have enough time to initialize itself:
--->                  while server._running > 1:
                            try:
                                sleep(1) # wait for interrupt
                            except Exception:
                                if server._running < 3:
                                    raise # shutdown

So, we skip waiting and freeze at an endless loop.
The fix may be the following:
ThreadedAppServer.py, line 1307:
                    # Run the server thread
                    t = Thread(target=_windowsmainloop)
                    t.start()
                    try:
--->                  # Inserting waiting loop before _running status check.
--->                  for i in range(30): # wait at most 3 seconds for startup
--->                       if server._running == 3:
--->                            break
--->                       sleep(0.1)

                        while server._running > 1:
                            try:
                                sleep(1) # wait for interrupt
                            except Exception:
                                if server._running < 3:
                                    raise # shutdown
                    finally:
                        t.join()

Can you please confirm that this fix is applicable?
We may throw an exception if wait was not successful.
Will it be a good idea to rewrite flags usage with python's events wait/set functionality to be on the safe side?

Thank you very much,
Mikhail

Re: [Webware-discuss] Freeze at ThreadedAppServer From: Christoph Zwerschke <cito@on...> - 2012-10-07 22:37 Am 05.10.2012 10:29, schrieb Alex Ivanov: > First of all, thank you, Christoph, for the excellent software! I've > been using webware since 2002 and have not yet seen a decent > replacement to it! Outstanding performance of lightweight servlets > implementation leaves behind its competitors with their tons of > useless code. That's the main feature I'm using from webware. > Upgraded recently to 1.1 and discovered a freeze when I press Ctrl+C. > It happens only on Windows. I'm using Windows 7. Linux is not > affected. In fact the reason of the freeze seems to be quite simple: Thanks for the positive feedback, kudos should go to the authors. Your analysis of the problem and fix look good to me. It's actually a race condition, and in fact most of the time it works on my test machine, but sometimes not. And it's not really a freeze, the server works properly, just doesn't respond to Ctrl-C any more, right? I also agree that a better fix would be to use a condition or event instead of the global flag. I'll work on that and plan to have a bugfix release this month. A couple of issues have already been fixed after 1.1, and I have one or two other open issues that I want to address. If there are other small issues that should be addressed in a bugfix release, let me know. -- Christoph

Re: [Webware-discuss] Freeze at ThreadedAppServer From: Christoph Zwerschke <cito@on...> - 2012-10-08 20:50 Am 05.10.2012 10:29, schrieb Alex Ivanov: > Can you please confirm that this fix is applicable? > We may throw an exception if wait was not successful. > Will it be a good idea to rewrite flags usage with python's events wait/set functionality to be on the safe side? I have fixed it now in trunk in r8233 with the simplest possible patch. Using events would be probably better, but I want to keep the semantics of the existing flag for backward compatibility. -- Christoph

Hi

I'm using webware for my website since 2007.
I'm using webware 1.0, because webware 1.1 didn't work correctly for
me (I don't remember why)

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.

I still have some actions to do in my investigations like:
- rebooting the server which is up since 620 days...
- 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...)
- reverting to webware 0.9

I intend to use gevent for the radius server, because I like it.
I would also like to use comet services for the web application, which
brings me to my question:
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.

Gevent is able to wrap standard python libraries (monkey patching) and
make standard code greenlet compatible, so I'm not sure the wsgi
wrapper would be complicated to do.

I have started to look inside the appServer. I don't know where to start.
There are quite some code that initializes different modules and
things like that.
In gevent, the idea is to spawn a greenlet for every new transaction.
I'm not sure there is a pool of workers.

Thanks for reading.

Re: [Webware-discuss] webware gevent based appServer From: Christoph Zwerschke <cito@on...> - 2012-09-19 15:01 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

Re: [Webware-discuss] webware gevent based appServer From: NoRaGen <noragen@gm...> - 2012-09-19 16:13 Attachments: Message as HTML      Hi, 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 Tobias ------------------------------------------------------------------------ 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 > Webware-discuss@... > https://lists.sourceforge.net/lists/listinfo/webware-discuss >

Re: [Webware-discuss] webware gevent based appServer From: Christoph Zwerschke <cito@on...> - 2012-09-19 18:08 Am 19.09.2012 18:13, schrieb NoRaGen: > It would be nice to have the option to upgrade to a python3.x Version > of Webware for later purpose. Definitely, that has also been one of my goals for a new version. > 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. The problem here is that Webware development started even before Python 2, so the old API is very old-fashioned concerning naming conventions, use of getters and setters etc. My idea was to add a tool like py2to3 that can convert an old style Webware app to a new style app. Another idea would be to allow both styles. E.g. request could become a property, but if you call the request object, then it returns self, so if you use request as a getter function, it would still work. We already discussed this in the past. Method names could be changed from camelCase to PEP8 style, but the old names could be kept as aliases. > 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. Yes, e.g. ReportLab is still one of the roadblockers. -- Chris

Re: [Webware-discuss] webware gevent based appServer From: Oliver Bock <oliver@g7...> - 2012-09-19 22:48 On 20/09/2012 1:01 AM, Christoph Zwerschke wrote: > So my question to this mailing list would be: How many people are still > interested in having a modernized Webware version...? I maintain a Webware app that does a lot of work, but changes rarely, and I'm not doing any new Python web development these days (I'm using C# so I can share code between a desktop app and web server). I only use mod_webkit2, WebKit and MiscUtils.DBPool. My preference would be to keep up with Python so I can keep installing Webware when CentOS upgrades its python, but otherwise stability is good for me. That said, none of the suggestions for updating APIs would particularly bother me - I like WebKit and will happily do what it takes to keep my application working. And thanks for all the work you do keeping it going, Christoph. Oliver

Re: [Webware-discuss] webware gevent based appServer From: Sophana K <sophana78@gm...> - 2012-09-20 07:59 I will give a try again with webware 1.1 It works, but not for a long time... python3 doesn't look like a priority for me. (I admit I had some hard time with unicode...) Backward compatibility for webkit is the most important IMHO. About naming convention, I don't care that much. I'm not using plugins. A little bit of TaskKit (not a big deal) Migrating to more modern server architectures is a big plus for me: more scalability, comet, etc... If it is possible to just use WebKit compatibility in order to integrate more easily with other python libraries, it would be great. Sophana On Wed, Sep 19, 2012 at 8:07 PM, Christoph Zwerschke <cito@...> wrote: > Am 19.09.2012 18:13, schrieb NoRaGen: >> It would be nice to have the option to upgrade to a python3.x Version >> of Webware for later purpose. > > Definitely, that has also been one of my goals for a new version. > > > 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. > > The problem here is that Webware development started even before Python > 2, so the old API is very old-fashioned concerning naming conventions, > use of getters and setters etc. My idea was to add a tool like py2to3 > that can convert an old style Webware app to a new style app. > > Another idea would be to allow both styles. E.g. request could become a > property, but if you call the request object, then it returns self, so > if you use request as a getter function, it would still work. We already > discussed this in the past. Method names could be changed from camelCase > to PEP8 style, but the old names could be kept as aliases. > >> 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. > > Yes, e.g. ReportLab is still one of the roadblockers. > > -- Chris > > ------------------------------------------------------------------------------ > 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 > Webware-discuss@... > https://lists.sourceforge.net/lists/listinfo/webware-discuss

My URLs normally look like this:

http://www.mysite.com/v003/?_s=xx0045&_id=BK807317371

but occasionally one arrives like this:

http://www.mysite.com/v003/?_s=xx0045&_id=BK807317371*;bcsi-ac-3CA58FAD43257DE1=1E08471000000005HI6/ziFwyMTzliaD2x6OYpIvEvYyAAAABQAAAK5uLgCAcAAAAQAAAPOKAAA=*

Some googling revealed that the*;bcsi-ac*... stuff is probably some 
basic authentication information added by a not-too-clever proxy.  It 
surprised me to also learn that the semicolon is a valid query item 
separator 
(http://stackoverflow.com/questions/3481664/semicolon-as-url-query-separator).  
If WebUtils.FieldStorage had known this then my code would have happily 
ignored this junk and my user would have been OK.

In my view nobody should go around adding parameters to other programs' 
URLs, so I consider this problem the fault of whatever added that junk.  
I thought I'd mention it for interest, and in case it affects anybody else.


   Oliver

Re: [Webware-discuss] Semicolon URL delimiter From: Christoph Zwerschke <cito@on...> - 2012-01-26 08:35 Am 25.01.2012 00:23, schrieb Oliver Bock: > In my view nobody should go around adding parameters to other programs' > URLs, so I consider this problem the fault of whatever added that junk. > I thought I'd mention it for interest, and in case it affects anybody else. You're right, WebKit's FieldStorage class does not support the semicolon as separator. This should actually only be a problem for POST requests with query strings which is a somewhat rare case. I have fixed this now in r8226 anyway. Thanks for pointing this out. -- Christoph

DBUtils 1.1 has been released.

DBUtils is a suite of tools providing solid, persistent and pooled
connections to a database that can be used in all kinds of
multi-threaded environments such as Webware for Python or other web
application servers. The suite supports DB-API 2 compliant database
interfaces and the classic PyGreSQL interface.

The new version is available for download at:

     * http://www.python.org/pypi/DBUtils/ and
     * http://www.w4py.org/downloads/DBUtils/

Changes:

     * http://www.w4py.org/DBUtils/Docs/RelNotes-1.1.html

User's Guide available at:

     * http://www.w4py.org/DBUtils/Docs/UsersGuide.html

-- Christoph Zwerschke

1 message has been excluded from this view by a project administrator.

Previous Messages

Next Messages