Of course, Twitter is all that.
And, it's so very, very much more.
I see Twitter as the leading edge of a whole new kind of Internet application. Email is great when you want to convey some information to a select group of folks and you don't care so much when they read it. Instant Messages (IM) are good if you care about 'presence' - that the person is online and can chat, usually to answer short questions. Text messages are the same but you cannot really put links to online resources in them (that are easily used) and are person to person only. Phone calls require the person to stop what they are doing and thinking to talk to you, and of course you cannot share a link to online data.
What if I want to share a small amount of information that is time sensitive (recency matters) and I want to shout it out to anyone in my circle that cares to listen. I could email, but it just drowns into the inbox and gets lost in the sea of much longer data in my inbox.
Twitter solves this need. Twitter lets you post short bits of information - including links - that are consumed by the folks 'following' you. Those folks might include your friends and family and if you so choose might include a pile of other folks too. I have my profile set to not protect my updates, so everything I post (that's not a direct message to someone) is on the public timeline of posts. It's out there, available to anyone following me, and to anyone following the grand flow of Twitter data on the public timeline.
The magic of Twitter - and of the family of new applications that will be like Twitter - is that software can 'follow' these 'tweets' (posts) and do keyword searches. I tweeted about a wine that we were going to share at dinner at a friend's house and several wine enthusiasts (and a few wine sellers) automatically started following me. A few replied with some information they thought I might find valuable. I had indicated one of my preferences, desires, and interests. And the twittersphere responded, automatically.
The future of Twitter-like applications is not about tweets like "I'm going to coffee now" but are rather going to be like "what's the best head phones for under $25?" - and data streams will reply to you. And systems will start to know you based on what you tweet about. And information that is relevant to you will become available to you without you having to go search it out. You will automatically become part of virtual communities that ebb and flow based on real-time *and* historical data flows.
Likewise, ideas like TwitterData are going to enable computer systems to more easily participate in this flow of data. I can foresee things like your car tweeting to you that it's getting low on fuel or that it's time for an oil change... or your house tweeting you that the temperature is getting really hot and it's near the time you usually leave for home and would you like to turn on the air conditioner? Twitter is an extremely low-bandwidth means for simple message communication across a common fabric - a fabric that can be used to provide an *ecosystem* to help pay for that fabric.
What do I mean? I mean that nothing is free. Someone has to pay for a service that connects all these parts, that enables all this kind of virtual community and communications and status updates. If we had to pay for it as a monthly service fee, we probably would not do so. But the ecosystem of Twitter can cover the costs because there is commerce available. I don't want to be bombarded with ads for things I don't care about (funny, since I'm in the advertising business). But I do want to hear about products and services that I do care about. If there's a great deal on a good bottle of Amarone, I would like to know about that. If my car needs an oil change I'd like to know if some local shops have a great deal on a change and some spiffy new synthetic oil. If my car tells me that it needs oil and three local shops tweet me that they want my business and offer me a deal, that's advertising I want.
These ideas are simplistic and are not indicative of the limit of what Twitter-like services can do. We've not imagined what we can do with this kind of data fabric yet. That's what makes it so exciting to me. I get the same tingle I got the first time I realized that the Internet was ideal for moving voice data to make phone calls, and the first time I realized that you really could do great video over an IP network. Only this tingle is bigger.
Twitter matters. In a year it may or may not be the dominant near-real-time internet messaging application. But it's set the stage for a whole new kind of collaboration and entire new sets of applications and services. And I'm excited to be in on the beginnings of it.
Oh, and if you want to follow me on Twitter I'm gherlein. See you in the Twittersphere!
[ add comment ] ( 2 views ) | [ 0 trackbacks ] | permalink |
( 3 / 212 )Before I get into technology, I want to once again offer my thoughts and prayers to all the lives affected by the service of our military. I wrote about it yesterday but today is Memorial Day. I'll echo my yoga teacher Mary Jarvis who said in a tweet this morning: "when will it stop?"
On to technology. It's no secret to those that know me that I chase the latest technology developments (hence the name of this blog). I was into Voice over IP way before Skype came along and I've spent the last 5 years developing IPTV technology for retail advertising at PRN. I was an early believer in convergence - the intersection of voice, video and data.
I see another convergence coming, but it does not yet have a name. It has a few sides to it. One important side is streaming technology. I'll forgive you from thinking "yes, of course, Greg: that's your field. Of course you think that." But I don't mean streaming media (at least directly). I've come to believe that the current real-time streaming technologies are not adequate for tomorrow's applications.
First we had voice streaming on the net, then we had video streaming on the net, next we will have data streaming on the net. Wait - what did you say? Data streaming? Indeed.
We're seeing it now - with services like Twitter. The data served by Twitter itself is valuable and necessary, but not sufficient. The timeliness of the data matters. It's broadcast and consumed on a timeline where the value proposition exists primrarily in real-time but also again in the ability to mine that data. The data is streamed and that's what makes it powerful. The best example of a legacy version of this is stock sales/pricing. Tomorrow we will have access to commodity goods sales prices this way. There will be streams of data and we, as consumers of that data, will pull, sift, filter and sort the data we want and need. And some of that data will be metadata (data about data) and some will be directly useful.
And some of it will be media. But the infrastructure for media 'streaming' is not where it needs to be to support this vision. A growing number of very smart people are realizing this and beginning to come together to seek common solutions. The Internet became the powerful commercial place it is because a similar effort happened years ago to make standards and try to keep companies on the same page. Before the Internet we had AOL and it was a closed walled garden. When Internet Service Providers (ISPs) opened access to the Internet and the Netscape browser created a compelling way for regular people to use the internet a whole new ecosystem was created. Few folks who are not technical realize the effort it took to make the core protocols work together (DNS, HTTP, HTML, etc).
Similar hard work is underway now to enable the next generation of technologies. On the media side of things one of the core MPEG Groups is hosting a conference this summer in London to address how to distribute media in this new context. The DVB Group in Europe is moving in a similar direction. China Mobile is feeling the pain of today's inadequate technologies and hs begun to formulate a problem statement. When you factor in other aspects of media - user generated content, or UGC - it is going to get far more interesting. Cisco, for example, bought Pure Digital, the maker of the Flip Camcorder. Cisco is moving from the network into the consumer electronics space, but the hard fact is that the Flip exists to make it easy to get UGC media onto the network. Distributing that content, and making the data stream aware that the content exists, has yet to be solved in an effective way. The solutions that are available are 'pull' technologies (where you have to go search for it) and they are proprietary and operate in the walled gardens of their creators.
Tomorrow's network will work across the walls of the gardens and it will be a combined 'push' and 'pull' - the metadata about the content will be pushed and consumers will sift, sort and filter like they do with Twitter today. The entire ecosystem will change, and probably more radically than the change from AOL to an open Internet. This will be a fascinating and compelling area of technology for the next few years, I think. And some will make a lot of money, and others will lose a lot of money. But in 24 months I bet the landscape will be radically different.
I look forward to helping to shape these technologies. It should be fun.
[ add comment ] ( 4 views ) | [ 0 trackbacks ] | permalink |
( 2.9 / 200 )Monday is a National Holiday, and all over America families have the day off and are probably planning on grilling and having some friends over.
Half a world away hundreds of thousands of soldiers are doing their jobs. All around the world thousands of sailors are underway and won't see their families for months. Five Naval Aviators off the Nimitz died this week when their helicopter crashed of Southern California. Marines and Soldiers are on patrol in Afganistan right now, seeking our enemies and protecting our allies. Kids are driving Humvees in Iraq tonight and might die from a roadside bomb.
Twenty years ago I was among those servicemen. I know what it's like to leave a wife at home and go underway, to risk my life to do what I thought was right and follow orders to defend my country. I served in submarines, and my stock answer to what I did is "we don't discuss submarine operations." I did not face hostile fire, nor did I face the horror of seeing my friends die from roadside bombs or sniper fire. I was lucky. But I understand the sacrifice. My boat - the USS Richard B. Russell SSN-687 - earned two Navy Unit Citations and a Presidential Unit Citation while I was onboard - and three Battle 'E' Awards as well. My four years onboard were more than intense and there is no civilian equivalent.
My heart bleeds inside with support for the kids in harms way today. My soul is ripped from the knowledge that we, as a country, have not done every last thing we could to ensure that those kids are in the right place, doing the right thing, with the right equipment and the right support and the right benefits when they come home... even my Conservative friends will agree that we could have done better, that we must do better. We can always do better - especially when it's our youth's blood being spilled. I'll avoid discussing if it's just or right or if we should be there. We are, and we're sending our future into harm's way. To do that without committing everything we have behind it is a sin, in my opinion.
This weekend - and especially Monday - may we all honor the lives lost, the limbs lost, the blood lost, the sanity lost, the marriages lost, the normality lost, by our Service Men and Women. They go into harm's way because they are ordered to, but also because they believe they are doing the right thing. May God bless them all, and hold them safe. And may we all honor, respect, and contribute to their well being. May we all find peace and respect, and hold each other and all cultures in respect in the months and years to come.
Happy Memorial Day.
[ add comment ] ( 1 view ) | [ 0 trackbacks ] | permalink |
( 3 / 177 )I operate by a simple philosophy around work and customers. There are only three rules:
1. Always make the boss (customer) look good.
2. Never surprise the boss (customer).
3. See rules #1 and #2.
Making the Boss Look Good
It's simple, really. Everyone wants and needs to look good. That usually means doing a good job - but it also means making sure that others are aware of that good job. It means not trying to pull the spotlight to yourself but instead shining it elsewhere - on the boss for supporting the efforts that led to the success, on the team that did the work, on the support staff that held it all together. Everyone wants to look good and everyone wants their boss to look good. I work directly for the CTO of my company, but he still needs to look good. He's selling ideas and strategies and pushing us in directions that might be different than before. The better I can make him look the easier time he has. So my projects need to work. the technology choices I make need to be wise ones. The staffing choices I make need to work out more often than not. Of course it's possible that you end up working for a maniac and you don't want to make him or her look good. You still need to do it. Even if there's no other reason to do so, it's your reputation you destroy if you don't. Others are watching you, and they will remember. I'm lucky to have a great boss (he's a big part of what makes me like my job). If you are not so lucky, ask yourself if making your boss look good enough to get promoted (away from you) might not be the most cost-effective move you can make?
If the 'boss' is the customer, this applies double. My Dad told me once that people don't do business with companies; they do business with people. Every customer is a person with his or her own needs. In fact, they might be trying to make their boss look good. Regardless, they want to succeed. My job is to help them do that. What do they need? Can I help solve that need somehow, even if I have to adjust my product or service a little? It might make the difference in getting a sale or not.
Believe me, if you make the boss or customer look good - honestly look good through success - you will bask in the reflected glow. A good boss will know that you are the secret sauce and will reward you. A bad boss will get his due, someday, never fear - and the others in your company will notice you and remember. It will help you, even if it's not you getting the direct spotlight for your successes. And if your customers think of you as someone that makes them look good they will buy from you again and again. Your competition will have a huge obstacle to even getting their attention. It's a sort of anti-competition's marketing weapon. And it's just plain being a good person too.
Never Surprise the Boss
Bad news does not age well. It's not wine or cheese - it's rotten food. If you sit on it the smell gets worse and it gets harder to clean up. And it might just infect you with something. If you have some bad news, the best thing to do is to tell the boss or customer about it right away!
Now, this does not mean a knee-jerk reaction and crying wolf. Unless you are entry level you need to apply some judgment to the problem and consider the facts. That may require gathering some facts, and evaluating options. It usually means coming up with a recommendation (and facts to back that up). But hiding a problem, or sitting on it and hoping it will go away - those are recipes for disaster. The boss (or customer) *hates* surprises. We all do (unless it's winning the Lotto or the like). Bad news is never fun and never welcome. But if you can present it while it's fresh, with facts, with some options and maybe even a reasoned recommendation... now it's something that can be dealt with.
The flip side of this as a boss (and a customer) is that if you don't want to be surprised with bad news then you'd better learn to not shoot the messenger. Because if you do then the next time your staff or vendor will likely say "let's sit on this a bit - Greg nearly bit my head off the last time I told him we needed to slip the schedule due to bugs." And what happens? Not what you want. Bad news stays hidden until the last moment and then it's a surprise. An ugly one most likely.
Those are the rules. Not too complex, really. Of course they imply that you are competant, that you can communicate in a mature way, that you will do your best, that you are not personally a maniac of some kind. But those traits are screened for in the hiring process and can be managed (usually). But as a philosophy, if you follow these rules you'll do well.
What rules do you operate by?
[ add comment ] ( 1 view ) | [ 0 trackbacks ] | permalink |
( 3 / 172 )Internet Protocol Television - IPTV - is a maturing technology. Many neighborhoods in the US can get AT&T UVerse which is a triple play voice-data-video built using a Microsoft-based Set Top Box. Smaller Telco players are offering IP Video delivered over DSL.
I got into the IPTV space over 6 years ago when I helped co-found Arkstream. We had a grand vision to enable live video ingest and playback as well as commercial insertion - but with IPTV streams. It's a long story about why we couldn't bring our product to market. Our CEO was Mike Hafferty and I learned so much about sales from him. Everything is a sale - even this blog is a sales tool!
I joined Premier Retail Networks over 5 years ago because it was clear that IPTV was the right solution for their in-store video delivery system. I've spent these last years building and honing that system into the award winning advertising platform it is today. If you want to see it, don't worry - it will be in a Wal-Mart store near you soon!
Along the way I've gotten a lot of practical experience with IPTV systems. There's other folks that are more academically oriented and can certainly argue their points, and there's obviously a bunch of folks who are doing big telco-type deployments who have a different set of perceptions. But my perceptions are around using IPTV for a media playback solution on a local network (not a WAN) where you play many clips back to back to create a seamless show. Some of those clips are ads, some are content. The system does not have a user holding an IR remote control. It's an autonomous system that has to self-heal and stay operational. After all, if it's not playing the ads, it's not making money.
One of the things I've come to strongly believe is that *TODAY* if you want to deliver IPTV stream you *must* use the Real Time Protocol (RTP) to do it. But then I diverge from the standard approach. The extremely smart folks at the IETF that volunteer their time to work out these protocol issues take the position that the best way to make it work is to split the audio and video into separate streams and then sync the streams at the playback device (Set Top Box). Of course, this is not how the broadcast world does it - they mix the audio and video into a single stream (called a MPEG2 Transport Stream) and then broadcast that over the radio waves or cable to get to the Set Top Box (STB). For some reason the IETF folks want to make it a lot more complicated by splitting up the streams.
I think that the MPEG2 Transport Stream (TS) is fantastic. It's already packetized into 188 byte chunks. It has a standard way to convey information about the stream content using Program System Information Protocol (PSIP). You can carry alternate language audio or even different video streams. It's proven, it's standard, it's well documented. If you are not using it, you should. In the streaming world many of the streaming server vendors interpreted the stream splitting and the associated other complexities (like the Real Time Control Protocol - RTCP) as just too complicated and unecessary for applications that are just going to put an onto the network. After all, it works on cable, why do something different on an IP network, right? Heck, just toss the already packetized TS frames into UDP and send it! Right?
Wrong. IP Networks are different because the transport stream goes into UDP packets that are delivered best-effort. Sometimes the network will drop a few packets accidentally or on purpose if the instantaneous packet rate is higher than it can handle. Sometimes a switch or a router will hold a packet in a buffer and the order of the packets is changed a bit for only a few packets. I could go on with some real-world stories but I probably should not - besides, that's boring. The fact is, packets get lost sometimes. None of that happens across the data link layer of RF broadcast over the air or onto a coax cable. But it does on IP networks and if you don't have a way to know how much it happens and when, you are doomed to letting your customers tell you your video is bad - at least until they find someone else to stream to them and they are not your customers anymore.
RTP has a field in it's packet header for a sequence number. That sequence number increments each network packet. A receiver can use that to put the packets back into the right order and to detect packets that are lost in transit. The RTCP extension to RTP provides a standard way for receivers to report back packet loss rates (and other data) to the source. This capability is crucial to be able to remotely detect, diagnose and hopefully repair an issue that is affecting the video playback quality. If the network has a mis-configured switch that is dropping 10% of your packets the playback will be terrible. Without a means to know that the packet loss is happening you may not know you have a problem until a customer calls to complain - and then all you know is that you have a problem.
The streaming vendors that just put transport stream frames into UDP packets without using RTP cannot possibly get a packet loss count. It's somewhat possible to use the continuity counter in the MPEG stream itself, but that is just a coutner that goes from zero to 16 and then repeats (4 bits). It's not sifficient to get a real packet loss count that's useful for diagnostics.
Now, back to RTCP. If you do split your video and audio into seperate streams you must use RTCP to communicate the data to sync the streams. But if you use transport streams, you don't need that. RTCP does also share back the packet loss data... but that's a lot of protocol/software complexity for such a simple thing. I said before that *today* I think RTP is the right answer - purely since it can measure lost packets. Yes, yes, I know, there's also a timestamp feild in RTP. I think it's bogus. The whole notion of seperation of layers is to let the network layer carry a payload without having to know about the payload. That's actually a big problem with RTP and MPEG. To properly set the timestamp field using the MPEG payload you have to decode the stream enough to derive the MPEG clock. Now you really are into complexity, not to mention paying for both the MPEG system patent *and* the video compression patent licensing. I know that some systems use the timestamp field, but most that I know of don't use it at all. After all, the clock data is already in the MPEG stream. If you do want to measure jitter you can still can - you don't actually need to duplicate data in the stream. It's almost as if the smart IETF folks were being TOO smart!
I think that for broadcast-like streaming of tomorrow that we may see transport streams carried in non-RTP streams. I specifically think that the Datagram Congestion Control Protocol (DCCP) is a great place to start.
Why couldn't we just put MPEG Transport Stream frames into DCCP packets? We'd get the lost packet detection, stream control, and the added benfit that the network core can deal with the streams and avoid congestion. It's simple, it avoids some of the complexity of RTP and all the complexity of RTCP. We'd still need a standard way to collect packet loss statistics, but heck, we could use a REST API for that. It's just simple enough to change the game.
Of course that's not where it's headed in the IETF. They want to carry RTP in DCCP packets. It's going to be interesting to see where the industry goes with this. Personally, most of it is too complicated as it is.
What do you think?
[ 3 comments ] ( 20 views ) | [ 0 trackbacks ] | permalink |
( 3 / 163 )
Archives
