On Seaside and State
27
March
Phil Windley writes about his experience at the Seaside.
For anyone interested in Seaside, you may also be interested in http://video.google.com/videoplay?docid=1029369558328427746″>this video of where Lukas is taking Seaside.
While I love this work I always seem to come away with a couple of nagging issues. One being the amount of memory required to store state on the server for many requests, which over time will become less of an issue.
Another is user-friendly URLs. I’m always hovering links to see where they’ll take me. Or clicking on search results that appear the most recent because they include the date in the path. While I don’t see this as much an issue combined with session state in URLs - something seaside can do - state alone in my mind reduces usability. Then trying to get my head around bookmarking state such that a year or more down the track a session could be resumed. What then happens when there’s been an application revision. Do we then need tools to store application & session state. That then raises the issue of resumed application state and how can we then cross the divide between old and new to update application sessions. Are we looking down the track at virtual machine images for software revisions. At what point do we get persistent, historical application data through the generations.
Another issue Phil raised in his yet to be implemented session example is the unguessable session keys. How much of a problem might security then be. And what additional measures are required to prevent session hijacking.
We seem to be headed towards tracking everything we do in our digital life. Hell I look at Twitter and think we almost already are, still I think we have a long road ahead of us when it comes to persistent historical storage of our digital lives.


