>> I have a complex table and many links on the page that are not >> book-markable. Will that be a problem in terms of too much session >> information?
The default session store in Wicket saves history in some temp files and only holds the current page in memory (well, the current page of any page map in case you use more). Say that's a very heavy page, taking up to 100K. And say you run a VM with 1 GB of dedicated memory. You can support close to 10,000 concurrent sessions (close, because obviously, you'll use memory for other things than just sessions). Changes are that you run into bottlenecks with processors and database utilization long before you run out of memory for one box. The only kind of web sites I probably wouldn't recommend Wicket as used by default for are sites like Google, Yahoo and CNN etc, where you can have enormous spikes in traffic that are very short lived. But... the good news with Wicket then again is that you can build your app entirely using bookmarkable pages (even stateless if you want, so that you can avoid *any* memory usage) so that clustering will be easy and cheap. On top of that, you can plug in your own implementations of things like session store so that you can decide when/ how/ where state should be kept. You have to weigh the benefits of the stateful programming model against your technical requirements. But you can use Wicket for most use cases if you give it a bit of thought. >> Would it be conceptually easy for me to write Javascript/AJAX and hook them >> into Wicket in a simple way? Yeah, that's fairly simple. You can either write snippets that are used by components/ behaviors that integrate with our regular AJAX engine, or you can even plugin your own engine if you'd prefer that. >> Its all about cost. The funny thing is that in most discussions out there people focus on the cost of servers/ memory/ etc. While probably for most people - basically for anything that doesn't have the size of Google - development and maintenance cost is often the highest component. So a good development model makes sense. >> we have absolute faith that it will have a lot of users according to our >> business plan. May I ask what you think is a lot (say hits per second and concurrent sessions)? Thousands? Tens of thousands? Hundred of thousands? Even millions? If you're talking about really large numbers, you need to be aware of the choices you make in your app, not only for Wicket obviously, and test for scalability from the start. Though if you're talking about thousands up to maybe a few thousands, Wicket should be able to handle it fine without you having to worry about using stateful components. Eelco --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
