[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Auth]Server vs Clent side

From: Scott
Subject: [Auth]Server vs Clent side
Date: Sun, 15 Jul 2001 10:58:38 -0700
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2+) Gecko/20010714

Nick said:

I think client side software is pretty much useless. People don't like
plugins, and historically, plugin take-up is slower that technology take-up
on the serverside. As well as that, there are plenty of environments in
which they simply don't work.

I agree that plugins won't work in many situations, and that getting serverside install would be a good thing. As far as a server side solution though, there has to be incentives for servers to install apps or provide a DotGNU page. Lets just say I have a monopoly on the desktop (95% of desktops are my OS) and I state that this fall, I'll give everyone a Passport, then servers will install a passport page to be able to offer this product because 95% of my users can use it and would be able to 1click shop (or whatever the case may be) but if only 2% of users have a DotGNU key then do I really care to cater to that 2%?. MS is working to tie the passport into hotmail and users right now, even before winXP has been rolled out as a way to put pressure on internet service vendors to adopt it.

the scary part of this is that 60% of servers are Apache open source products (I'm aproximating but as far as Open Source goes we have the webservers as a majority already) and that MS will likely offer close apps that run on top of this OR tie the package into MS server OS like Win2K. Now in order to offer up the Passport service the easiest way becomes to install Win2K, and once I have to pay for Win2K, that Linux/Apache combo price factor doesn't seem so appealing because I have to buy Win2K anyhow and in this way MS will attempt to wedge it's desktop monopoly into the server market. Even running an MS based apache Module, the app may not allow looking for auth anywhere but at a passport url.

If we create a Server side component, I think an Apache Module is a good place to start and hopefully working with the good poeple over at Apache, our DotGNU module could be shipped as one of the Modules that is included with the server (and perhaps even turned on) By Default. This is where we can use our strength in the server market to get a great critical Mass out the door. add to this that in the near future many will be upgrading to the new Apache 2.0. Once we show that an alternative way of using a hailstorm app with a different way of Authentication, if MS Locks that DotGNU out of their server software with Close source, even though the standard they created states that you should be able to do otherwise, this is more ammo for the antitrust suits against them in progress now, they'd kind of HAVE to respect DotGNU or look real evil.

A client side browser plugin has the benifit of giving the end user a choice right off the bat, and would allow a robo-form-filler as an alternative for sites that don't yet support passport like features. At the same time, it would be ready to act as a passport/DorGNU auth server when that option was available. and the client won't have to put all their data out on a remote server if tey want to keep it locally.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]