But good frameworks and protocols permit different clients to work together, and still provide new "feature" continue to introduce new things quickly. E.g. I use Eudora. You use Outlook. You cand send me email where the body is in HTML, and if my client can grok it, it displays email as a web page. If my client can't, I see see the raw HTML, *BUT* I have the opportunity to go find a client application (not service) that *can* display the email right. Similarly, another person's the Netscape email client can send an "embedded" image that my Eudora email client can use as a background to email it displays.
Another example: if you send me an attachment for an application that I don't have (e.g. MS Project), I can extend my email application (actually, extend my PC) by adding that application -- *Given that* the client (my PC) is open, and extensible.
Has the fact that we have different email clients that *may* be non-interoperable prevented innovation from happening? No. The key is, though, that the underlying architecture presumes the endpoints can be changed to provide access to the new feature. This, in fact, encourages experimentation, and increases the rate at which new things emerge.
In addition, did my ISP offer this new functionality to me as a 'service'? No. Why not? Because there's no money in offering HTML email content as a 'service.' But by having endpoint flexibility and standard protocols (e.g. email headers, MIME, HTML), we can provide new features that are good for end users *even if* there isn't a market for a 'service.'
Would Napster have gotten started if the kid starting it had to convince UUNET that there was a market in letting people share MP3s online?
Now, will having different VoIP phones that *may* be non-interoperable prevent innovation? No. Would intelligent, open, extensible ones encourage rapid advancement? I certainly hope so. VoIP needs to be more than just a change in transport to be worth accepting.
Your statement started -- in the 2nd sentence -- by saying "in order to offer a service...." This is where your brain is stuck. New technology and feature advancement *mostly* happens via *applications* that run on endpoints, not by service providers thinking up new stuff that represents a big enough market for them to go sell something into.
Intelligence in the endpoints is all *about* not waiting for the "big boys" to decide whether we should have a service. We plug a SIP-enabled, extensible (via java, windoze, or whatever you want) IP phone in, and start doin new stuff -- *without* waiting for AT&T to decide to "offer it as a service."
And as for the "lower cost solution" argument, if you were correct, everybody you know would be using a VT100 connected to a VAX. Even the *web* presumes intelligent, extensible clients. Can you say "browser plug-ins?" What does the rendering of animated GIFs on your screen? In what context does a PDF file show on your PC? Do you have WinAmp on your PC? Does your PC store cookies that a server can retrieve later? Does your browser run JavaScript within web pages that it downloads? All these things get *content* from the network, but the content is executed/rendered *locally* on your PC.
Programmable, end-user-extensible SIP phones will rule. Network-based intelligence gives too much power to the people in the network. Give me my freedom.
Slashdot Mirror
Another example: if you send me an attachment for an application that I don't have (e.g. MS Project), I can extend my email application (actually, extend my PC) by adding that application -- *Given that* the client (my PC) is open, and extensible.
Has the fact that we have different email clients that *may* be non-interoperable prevented innovation from happening? No. The key is, though, that the underlying architecture presumes the endpoints can be changed to provide access to the new feature. This, in fact, encourages experimentation, and increases the rate at which new things emerge.
In addition, did my ISP offer this new functionality to me as a 'service'? No. Why not? Because there's no money in offering HTML email content as a 'service.' But by having endpoint flexibility and standard protocols (e.g. email headers, MIME, HTML), we can provide new features that are good for end users *even if* there isn't a market for a 'service.'
Would Napster have gotten started if the kid starting it had to convince UUNET that there was a market in letting people share MP3s online?
Now, will having different VoIP phones that *may* be non-interoperable prevent innovation? No. Would intelligent, open, extensible ones encourage rapid advancement? I certainly hope so. VoIP needs to be more than just a change in transport to be worth accepting.
Your statement started -- in the 2nd sentence -- by saying "in order to offer a service...." This is where your brain is stuck. New technology and feature advancement *mostly* happens via *applications* that run on endpoints, not by service providers thinking up new stuff that represents a big enough market for them to go sell something into.
Intelligence in the endpoints is all *about* not waiting for the "big boys" to decide whether we should have a service. We plug a SIP-enabled, extensible (via java, windoze, or whatever you want) IP phone in, and start doin new stuff -- *without* waiting for AT&T to decide to "offer it as a service."
And as for the "lower cost solution" argument, if you were correct, everybody you know would be using a VT100 connected to a VAX. Even the *web* presumes intelligent, extensible clients. Can you say "browser plug-ins?" What does the rendering of animated GIFs on your screen? In what context does a PDF file show on your PC? Do you have WinAmp on your PC? Does your PC store cookies that a server can retrieve later? Does your browser run JavaScript within web pages that it downloads? All these things get *content* from the network, but the content is executed/rendered *locally* on your PC.
Programmable, end-user-extensible SIP phones will rule. Network-based intelligence gives too much power to the people in the network. Give me my freedom.
-jb