[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 msn.com 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.
- [Auth]Server vs Clent side,
Scott <=