GAE Web2py App

[Robin B]

This app is up on GAE: http://ru.ly

I had to disable sessions to get it running.

Here is a stack trace: http://ru.ly/m :)

Robin

[Robin B]

Looks like the problem with the session was caused by this:

session.flash=T("OK, %s accepted." % item)

It works if I change to this:

session.flash="OK, %s accepted." % item

Looks like the translation could not be pickled.

Robin

[Massimo Di Pierro]

You should do.

> session.flash=str(T("OK, %s accepted." ,item))

[Robin B]

Does web2py clean up expired sessions that are stored in the db?

GAE does not have background tasks (yet).

Robin

On Jul 10, 10:09 am, Massimo Di Pierro <mdipie...@cs.depaul.edu>
wrote:

[Massimo Di Pierro]

No.

[Massimo Di Pierro]

Let me add.... sessions expire only on admin and admin does not work
on GAE.

Normalr sessions never expire. If you want then to expire you need to
implement it for example

session.connect(request,response.db=db)
if session.last and time.time()-session.last>TIME_EXPIRE:
# remove this session from GAE
# open another session
session.last=time.time()

Massimo

[Robin B]

For production, I am worried about letting stale sessions pile up.

When an app is running for weeks, the growing number of stale sessions
will degrade response times.

I would normally use a cron task to purge sessions older than 2 weeks,
so they do not accumulate.

GAE does not have cron, so instead, when a new session is created,
based on some tiny probability, I would expire old sessions.

When GAE adds something like cron, then it would be more
straightforward.

Robin

[Massimo Di Pierro]

I agree.

All I am saying is that web2py cannot do that automatically because I
do not know how you define "expiration".
web2py (on GAE) stores the last modification data in
db.web2py_session.modified_datetime. You can easily put a db
(...).delete() at the top of your code that deletes all sessions that
have expired since the last access. You just have to define what it
means for you to expire. i.e. what to put in (...)

Massimo

[Massimo Di Pierro]

Let me add I consider it a feature that web2py never deletes any data
without you being explicit about it.

Massimo

[Robin B]

Being explicit when deleting data is certainly a good thing.

That said, is there any notion of a web2py plugin?

Rails has its plugins, which are nice for sharing small pieces of
functionality.

The problem is that plugins are so useful that people have plugins
that depend on plugins!

So it becomes a dependency and versioning headache.

The ruby web framework called merb learned from Rail's mistakes and
uses ruby gems for plugins.

The benefit of gems are versioning and automatic/explicit dependency
management.

Once cool idea is that new features could be introduced as plugins and
later included in the standard distribution, and deprecated features
can be pushed out to plugins so the functionality is available but
does not result in framework bloat.

I know python has eggs which are similar to ruby gems.

Thoughts?

Robin

[Robin B]

The reason that I ask about plugins:

Things like, deleting data, should be optional and explicit.
Common tasks, like removing stale sessions on GAE, should not have to
be reimplemented by every developer.

Installing a 'session sweeper' plugin would be both explicit and
reusable.

Do plugins somehow contradict web2py's top-down design?

Robin

[Massimo Di Pierro]

This can be done. But the plugin in this case is merely a 5 lines
file that stick in the models section. when the app is called it does
the sweeping.
You just need to write the plugin, there is no need to make any
change to web2py to make this work and reusable.

Massimo

[Robin B]

If plugins are just adhoc, then plugins become a versioning and
dependency problem, and just like rails plugins, difficult to
maintain.

If there is a bug fix in an existing plugin, how do people get the
update?
If a plugin depends on other plugin, how do people resolve the
dependency?
How should people publish and install plugins?

Copy/paste or manually pulling a tagged revision from a repository are
what creates the maintenance headache.

Ruby Gems completely solved the problems of packaging, distribution,
versioning, and dependency, so something similar would make plugins
actually maintainable.

Robin

[Massimo Di Pierro]

That is not what I meant. There should be rules. There should be good
practice docs. There should be an app to manage them.
Make a proposal. Until I complete the current task the book) I have
no time to think about this.

Massimo