- From: Brad Neuberg <bkn3@columbia.edu>
- Date: Tue, 08 Jun 2004 12:48:47 -0700
If things are done on the server-side, then the question becomes what does this look like to the server-side programmer? If the server-side programmer just does things by the Web App standards, then we would need a custom preprocessor that would intercept this and change it into what IE would need. I am a JSP programmer so I know this is possible in JSP (you can intercept the HTTP response in a standard way and change things), but I'm not sure if it is possible in other popular environments in a standard way (PHP, Perl, ASP/ASP.Net, etc.). Also, remember that there would be an adoption curve on the server side as well; would web hosting providers install these convertors? If things are done on the client side then the server-side doesn't need to change. I think there are three metrics that are very important for this working group to consider. First, what will be the reliability of using these web app standards? Will it be a pain because things work slightly different across the different browsers, so much so that it is just easier for me to just use Flash or another standard? Second, is it easy to use? Were so many compromises made in creating it that it is extremely difficult to use? Finally, what is the performance? Is it fast enough for users to actually enjoy? To summarize, these three metrics are Reliability, Ease of Programmer Use, and Performance. The reason I brought these up in a discussion of whether to put the emulation layer on the client or server sides is because if we can't achieve these three important metrics on the client side then we may have to do it on the server-side. Brad Neuberg At 12:35 PM 6/8/2004, Preston St. Pierre wrote: >Hey guys, just a few comments: > > > 1) do everything in the client > > pros: simple installation of web forms (plug & play) > > cons: performance in the client is degraded (is this a bad thing? we are > > talking about explorer) > >If we do everything client side, we need the support of people. People, >essentially, are idiots. They do what Microsoft tells them (for the most >part, of course). If Microsoft has goals that lie in other directions, it >would be easy for them to break compatibility. This standards group is >partially here to block the proprietary MS stuff from becoming a standard. >When 90% of the population is governed by one body, and that body is >against what we are doing, suddenly we fail. Yes, everyone has proposed >work-arounds. But do we really want to be designing standards based on >work-arounds? If so, it will eventually be "Well we'd like to do it this >way, but it would be 10x easier to implement on IE if we did it this other >way, so we'll do that." The first way may have been much better, but >client side and IE crushes it. > > > 2) introduce server-side solutions (xsl, jsp etc) > > pros & cons: the reverse of the above > > another con, do we want to say: > > "to implement web forms 2 you will need php version 4.x...?" > >In response to your second con... what do you honestly think is better: A >company that can install a (free, btw) server mod (php) and have their >site work on all clients, or a company that makes all their clients >install a plugin of their own? The obvious answer is that it is better to >be on the server side. There are other things to consider, too. It is much >easier for a company to have freedom of open/closed source when the >technology is server side. Everything suddenly becomes more secure. Yes, >there is more overhead on the server, granted. Do you think that Linux + >PHP + Apache + WebForms is going to be slower than Longhorn + IIS + XAML? >I doubt it. I doubt it highly. > >I do a lot of web applications programming, and server side technologies >have done nothing but make it easier. I joined this mailing list to be >sure that a "regular" programmer is around. Too many times standards >groups get lost in speculation and end up with something that isn't >usable. As far as I'm concerned, client side technology is too insecure. >When the user's browser chooses how to interpret my code, it may come up >with a different result than I had intended. Server side, I know the worst >it can do is morph how my page looks. > >Just some thoughts.
Received on Tuesday, 8 June 2004 12:48:47 UTC