cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ovidiu Predescu <>
Subject Re: AW: [RT]: Session support
Date Tue, 09 Oct 2001 23:17:16 GMT
On Tue, 09 Oct 2001 17:49:25 +0200, Joerg Henne <> wrote:

> Bernhard Huber wrote:
> > 
> > You are right about the WML redirect troubles.
> > To some degree you may avoid that by using cocoon Actions,
> > avoiding using redirects.
> > I'm not saying that WML redirect can be avoided completly,
> > but you may try to avoid using redirects, as much as
> > possible and using Actions to handle some sort of
> > action if some application constraints are not met.
> our "solution" was to use fake redirects for WAP: WML pages containing only an
> empty card with an event handler "onenterforward" which issues a <go>.
> However, this is not very satisfying as it requires lots of additional stuff
> in the sitemap.

As part of a solution I had implemented some time ago I used a multitude of
techniques to deal with session support on WAP devices.

One technique used a WML variable on the WAP browser to hold the session id.
The first page sent to the device would set the session id using a technique
similar with the one you describe above. For this to work, a special XSLT
stylesheet took care of rewriting all the links to have the device pass the
value of its session id variable. This solution worked only on WML 1.1 phones,
if I remember correctly.

A similar technique used the unique subscriber id, passed in by most of the WAP phones and/or gateways, at least here in US.

If the above two solutions failed, we reversed to the URL rewriting, which as
noted earlier, is not only bad from the cache perspective on the server side,
but it also occupies a lot of the precious memory available on the WAP device.
It is however the solution that always works, no matter how old the WML
implementation is.

The trick was to try to try to use all these methods at once, when a device
connects for the first time to the site. Based on response obtained when the
user clicks on the first link, the logic decided which option to use.

Ovidiu Predescu <> (inside HP's firewall only) (my SourceForge page) (GNU, Emacs, other stuff)

To unsubscribe, e-mail:
For additional commands, email:

View raw message