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 Wed, 10 Oct 2001 16:04:40 GMT
Hi Joerg,

On Wed, 10 Oct 2001 11:44:51 +0200, Joerg Henne <> wrote:

> > 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.
> Well, the funny thing is that this doesn't seem to be entirely true,
> due to the fact that the WML gateway performs a peculiar kind of
> compression on the data. We have the situation that we have a
> large(ish) list of links which all point to the same URI (rewritten
> to include the session id) but with different query parameters. E.g.
> <anchor>link 1
>   <go href="page;jsessionid=xxx"><postfield name="foo" value="1"/></go>
> </anchor>
> <anchor>link 2
>   <go href="page;jsessionid=xxx"><postfield name="foo" value="2"/></go>
> </anchor>
> ...
> In this situation the WAP gateway will compile a string table (you
> can use the Nokia WAP toolkit to display a compressed WML stack PDU)
> which contains the href only once. You don't have to set a variable
> or such. However, you still lose the valuable space at least for one
> instance of the session ID.

Yes, indeed, the WAP specification for the WML 1.1 compiler describes
the compiler can place the strings into a string table and then refer
to them by index. Thus in situation like above the value of the "href"
attribute will be placed in the string table and simply referenced.

If I remember well however, one string table is created per page, so
you cannot share the same string across multiple pages. What this
means is that multiple pages will keep the "href" value multiple times
in their string table. And since the browser maintains the pages in a
list to provide history, you'll have the "href" value multiplied
several times. The problem aggravates even more with longer "href"

Now probably this is no longer an issue with newer devices, that have
a lot bigger memory, so maybe it's not worth trying to implement a
more complex solution.

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