IMHO, from a user perspective, to let more users accept Tapestry, Tapestry should consider more for the users. Compatibility and the ease of upgrade should be a high priority. Tapestry should build a kernel that lasts over time. Drastic changes from release to release will drive users away. A large user base and community is very important for an enterprise user. I like Tapestry but as a architect in a big company, I may have to reconsider my choice if Tapestry can not reach a stable stage within six months. Every upgrade is a non-trivial cost for an SEI CMM level 3 organization that is targeting CMMI level 5 certification. For me, it's more important to have a stable, well optimized and well documented Tapestry.
Best Regards, Cliff Zhao On 11/28/05, Davor Hrg <[EMAIL PROTECTED]> wrote: > > I'm no expert in .NET bu have seen aplications killed with VIEWSTATE, > one page had a viewstate of 75 kB, which means 150 kB of traffic per > request. > > I'm affraid this could break the "easiest way should be the right way". > > I hope someone with more .NET expirience could elaborate more on the > VIEWSTATE issue. > > On 11/28/05, Danny Angus <[EMAIL PROTECTED]> wrote: > > > > Massimo Lusetti wrote: > > > > >I've to admit, as a global note, I'm not very comfortable with storing > > > states (and consequently what relates to states) on the client > > > > I agree with Massimo, not only does bandwidth become an issue, but > > security > > becomes more of an issue as well. > > > > I'm not saying that it would necessarily expose a weakness, but it might > > make it easier for less-experienced developers to inadvertently expose a > > weakness. > > > > For example if it is possible to manipulate the client-side state, and > we > > have to assume that if we can do it then it is possible (if difficult), > so > > we have to ensure that every precaution is taken to ensure that we > > validate > > the state against allowable states for that user. In practice this is > not > > trivial, we have to identify the appropriate validation to use for each > > application and set of data. The real danger of this is that we really > > would be seeing a move to a less secure model. > > > > Lets look at an example; If the state recorded is an account number for > an > > account you are allowed to administer we can let you see your account > > details, but how can be be sure that you are still the person who is > > entitled to see that data? Obvious we make you log in (and http_auth > > ensures that the browser sends your password with every logged-in > request) > > and compare the user we retrieve from the server with the one associated > > with the client-side state, in our example we also have to verify that > the > > account is associated with a user you are allowed to administer. We will > > pretty quickly end up wishing that we had a server-side state we could > use > > to validate requests against. Doesn't this defeat the purpose? I though > > that the whole principle behind sessions and session-id's was about > moving > > state from the client into the server where it is secure and can't be > > tampered with. > > Is it not possible to split the state intellignently between client and > > server? > > > > As far as bandwidth is concerned I'm quite sure that my employer would > be > > somewhat less than pleased if my new application consumed more bandwidth > > than an equivalent older one, someone has to pay for bandwidth and its > > often both parties, naievely put for a 100% marginal rise in traffic > > between two parties you get a 200% rise in marginal cost. > > > > d. > > > > > > > > > *************************************************************************** > > The information in this e-mail is confidential and for use by the > > addressee(s) only. If you are not the intended recipient (or responsible > for > > delivery of the message to the intended recipient) please notify us > > immediately on 0141 306 2050 and delete the message from your computer. > You > > may not copy or forward it or use or disclose its contents to any other > > person. As Internet communications are capable of data corruption > Student > > Loans Company Limited does not accept any responsibility for changes > made > > to this message after it was sent. For this reason it may be > inappropriate > > to rely on advice or opinions contained in an e-mail without obtaining > > written confirmation of it. Neither Student Loans Company Limited or the > > sender accepts any liability or responsibility for viruses as it is your > > responsibility to scan attachments (if any). Opinions and views > expressed in > > this e-mail are those of the sender and may not reflect the opinions and > > views of The Student Loans Company Limit > > ed. > > > > This footnote also confirms that this email message has been swept for > the > > presence of computer viruses. > > > > > ************************************************************************** > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > >
