Search This Blog

Tuesday, February 27, 2007

BLISS -- Service Interoperability

Those of you who have been in the industry long enough know that the vision of SIP is not fully realized because of interop issues between vendors with the most basic of business telephony features.

There have been various efforts by industry groups like the SIP Forum and individual vendor initiatives like Sylantro usually results in competitor comments about the implementation being proprietary, etc. The back-and-forth understandably keeps going on. This ends up frustrating customers and end users.

There is hope finally! The SIP chairs have now decided to tackle this services interoperability issue head-on by getting together a BOF called BLISS. The name is apt and I would strongly recommend that any of you who are in the industry support this initiative and actively participate in the discussion.

Saturday, February 24, 2007

Off for a few weeks

Hi Readers,

Just a short post to let you know that this blog just may be quiet for the next few weeks (hopefully shorter). I am in the process of discovering how lovely yet strenous it is to manage our newborn son :-)

A Note to my friends from Russia: Thanks for your email - I apologize for not having responded yet - I will certainly put some thought on your questions and write back by next week.

Thursday, February 15, 2007

Lemonade 2.0

(c) Corporaterat (please retain copyright if you copy)

Oh just a cartoon. Sometimes, I get the itch to draw.

Tuesday, February 13, 2007

Indexing should get smarter for bloggers

There are several reasons why Bloggers post. A part of it, I believe, is to share technology and for many, including me, it is a great tool to meet like minded technology people, who often respond by private email. But, I'd be willing to go out on a limb and state that the biggest reason most bloggers blog is that they like to have a podium to talk and be heard, albeit virtually. This also means, therefore, that a vast majority of the bloggers (including me) are 'hitcounter'
maniacs. We love to log in and see how high up our 'hit count' is for the day, and who referred to us. There. I said it. Nothing wrong with it. I love what I call 'ego searching'. It's not a term I invented. PhpBB forums have used this term for many years.

And this is where I think major search engines like Google and Yahoo can do a better job. See, both of them give you an option for either searching within other blogs (who in the blogosphere links to you) or the whole web. The former is limited while the latter is problematic.

Let me explain. There is a difference between adding an analytics tool to your site vs. searching for who links to you. The latter is a superset of the former. The analytics tool will catch referrers (assuming they are not locked) only if the referring site results in a click to your site.

I often use Google Webmaster tools and Yahoo Siteexplorer to see 'Inlinks'. And the problem is that every time someone popular links to this blog, the links go for a toss.

Take for instance, a couple of days ago, Jeremy Zawodny linked to one of the pipes I created with Yahoo Pipes. Admittedly, I haven't been reading too many blogs in the search engine world, but it seems Jeremy's blog is heavily read and linked, so that in turn resulted in a good surge of hits to my site. I think that is fantastic. But here is the rub, when some post gets added to a person's blog-roll or a sidebar and the blog re-published, both Goog and Y! assume that every page in their blog that shows the same sidebar naturally must refer to me as well. Net result, I get 100s or 1000s of 'false inlinks' as I call it. This happened before as well, with another site who had added me to their blogroll and I saw 100s of false-positives. Well, they are not really false-positives - since it is a sidebar, it does actually link to my site, but search engines should be smarter while indexing and do a little better with this.

1. add a voluntary tag which bloggers can put into 'sidebar' or 'blogroll' entries like , say, "indexOnce" which means even though this part of every page, it does not mean everypage is talking about it.

2. Get a little smarter at the indexing as well.

Monday, February 12, 2007

Burn those virtual calories

"Please change MOV AX,0 to XOR AX,AX. You save bytes. Also, please use shift operators instead of divisions. You save on cycles"

Common speak during the days of DOS and protected mode coding – when C and ASM worked hand in hand.

Then came the ‘abstract high level programmers’ who never really cared about declaring an int where only a byte is needed, or use multiple structs where a union would suffice.
Then came the ‘Object Oriented’ programmers who never really cared for understanding how virtual functions really worked or how they affected performance and/or size and used it pretty much everywhere without blinking an eye.
Then came the visual programmers who would love to drag and drop ‘graphic objects’ that would increase productivity by 150% and reduce time to market by 300% ! Woo haa. It’s another matter that each ‘visual object’ generated 300-500 lines of gob.
Then there was XML & buddies – the whoopie-doo do it all markup language for representing anything.
And DHTML and Javascript to add funky effects and client side programming to increase ‘web interface coolness’.
Then came the idea of using the Internet for communications !
Then came SIP, a great text based protocol, which generates anything between 500-1000 bytes for each message that passes to and fro, with the capacity of ‘adding more as it goes along the network’
Then came ambitious vendors who stuffed ‘SIP’ with a gazillion features like X-Vendor-Header:my.state=park.activate or X-Vendor-Header: (actual JPEG thumbnail here!) which generated anything between 1000-8000 bytes per message !
Then came the world of AJAX with a gazillion websites blindly embedding large JS ‘libraries’ to provide fancy effects.
Then came the first level of convergence – chat & email together ! see this
Then came RIA – combining funky web stuff with cool VoIP stuff- all on the internet – IPTV, VoD, and all the fun things.
Then came an abundance of soft-phones like Skype. Eat up as much memory as you can give it. Infact, I even talked to another vendor in a similar business and he said "Who cares! add more memory!"

Whoopie-Do. Who cares about size, right ? Broadband Rocks. CPU power is king.

Then came the problem of deploying all of the above en-masse.

XML led to Binary-XML. It was felt that for many applications, the XML schema definition itself far exceeded the content it was carrying.
Then came JSON, the ‘fat-free’ alternative to XML
Then came SIGCOMP, a mechanism to ZIP SIP, so to speak, so that it could be used effectively for mobile networks.
Also came the call by the SIP authors to stop using it as a protocol to carry anything under the sun.
Then came the call by AJAXers to have browsers ‘do more stuff’ so they don’t have to pass large libraries around with each page.
Then came reports for first IPTV deployment. Performance mostly sucks.
Then people started complaining about soft-phones eating up every inch of their precious memory and network bandwidth. (Gee, so people really care for memory, it seems)
Then a few months ago, I was taking to a friend who plans to revolutionize the IP-video market by doing things no one is concentrating on today.
“How?” I asked naively.
“We are writing optimized device drivers in assembly and C to ensure that we get the most out of CPU performance, reducing our client size by half to ensure better processing time, (amongst other things)”.

“But.. But.. Broadband! Visual Programming ! I sputtered in rage”

The network speed and CPU power are no excuse for optimization. Burn those virtual calories.

Saturday, February 10, 2007

Just a reminder

Dear Readers,

just a couple of notes:

1. For all those who are subscribed to my feed via email, please ensure that you have verified your email. When you subscribe via email, feedburner will send you an email to verify your address. If you have not received and acted upon the email, you will not get my feed delivered. I see a good number of people in the 'unverified' state, so please check your status. Also note that the 'feed by email' is sent out at 9AM each day, if there was a new feed before that. So it is not instantaneous (I don't control it - feedburner works that way)

2. My feed should now be working properly, ordered the right way, thanks to the wonders of Yahoo Pipes - I simply created a pipe to sort blogger feed by published date and use that as a feed to feedburner. What a great tool, this Yahoo Pipe. So for all those who were affected by the mess before, despair no more !

Friday, February 9, 2007

Piping Hot: Are VoIP bloggers really original?

Are VoIP/Convergence/Telecom/SIP bloggers really original or do they just keep picking up posts from each other?

Let's have some fun. I wrote up a Yahoo Pipe (What?? you don't know what they are??) that compares the feeds from:
      Then filter them for voip/convergence related posts, then selects only those that after analysis seem unique, sorts 'em and then creates a new feed just for you.
      Check it out here and see what happens when the above four blogs are put to the 'copycat' test :-)
      I applaud the Yahoo team for coming out with such a great tool to let users apply diverse data into a personalized flow. Raw Data becomes useful information, only when you provide the right means to personalize them.
      (Disclaimer: This post is just an excuse for me to test Yahoo Pipes - a very very nice new concept in personalized aggregation. It is not really meant to discover if we are all original or not - so don't complain if you think the algorithm for originality is rubbish!)
      For a more serious example of how it helps, remember my earlier post where I was complaining that the new blogger beta was sorting feed by update date not published date, and this resulted in old posts showing up for all my readers even if I fixed a typo? Yahoo Pipes solves it so simply - all I had to do was create a new pipe with a 'fetch' for my blogger feed and then sort it by published date and then export that feed to my feedburner input. Simple huh ?
      Or, take another little more complicate example, where in addition to providing site feed, I show how to also add another feed attribute which shows who all links to each post.
      Note: Yahoo Pipes is very slow after launch. Yahoo says too many people are overloading it - they hope to get better in a few days, so if you see no output of my pipe, run it again !

      Thursday, February 8, 2007

      Web 2.0: The machine is us/(ing us)

      A friend of mine passed on this great video at YouTube by Michael Wesch (Assistant Professor of Cultural Anthropology, Kansas State university). I also noticed that Alec Saunders has it on his page too, so it looks like this video is making the rounds.

      I thought it was simply fantastic. A tip of the hat to Professor Wesch and his team. Enjoy.
      (Keep your speakers on).

      And then, once it excites you, how about diving into some details of web 2.0 :-)

      Wednesday, February 7, 2007

      Flash vs. AJAX – Which to choose for Internet Based Communications ?

      There is no dearth of articles on the internet about the virtues of Flash over AJAX or the other way around. Arguments range from “proprietary plugin vs. open solution”, “performance vs. bandwidth”, “download size”, “availability of skillset”, “security” and much more. However, the focus of my topic is very specific. What is the right RIA platform/technology to use for ‘Internet Based Communications’ related development ?
      In Summary,if you want your product be successful in the market in 2007-2010 and if you need real-time voice, video and animation Flash may be a better choice today. If you need to support mobile clients, stick with Flash. AJAX is great for semi-realtime solutions like IM chats, Web Based Desktop experience, document collaboration etc. Infact, I blogged about it’s promise earlier. But not for voice/video/animation intensive operations.

      Here are the details (PLEASE NOTE – all of this is in context of building ‘Communication Applications on the Internet’)

      First, let me classify what I term as ‘Internet Based Communications’ (IBC) and the primary components that need to be considered there.

      My definition of IBC is ‘a multi-dimensional mode of communication, where one or more users interact with each other and or innovative services using a combination of, but not limited to, voice, video and multimedia messaging in a way that enhances their user experience for interaction’ (no, I am not a lawyer - it is just so hard to get all dimensions into a sentence)

      Before we discuss the right RIA choice for IBC, let us first look at the primary components and their nature as far as ‘load on network’ is concerned (click image to see larger version). The 'bandwidth' understanding is useful to judge whether it is better to do this locally, using local CPU power, or remotely and then have it 'sent to you' as 'frames'.

      Within IBC, what are you making and what is your target market ?

      Deciding on a target market and what you plan to do is critical to decide whether you should go the AJAX way or the Flash way. For example:

      • Is your browser going to be your only client ?
      • Do you expect voice and video to be a part of your service ?
      • How important is security to your product, in a span of now to 5 years down ?
      • How important is ‘animation’ and ‘interactivity’ in your product ?
      • Is making your IBC product available on mobile phones important ?
      • What OSs do you need to support ?
      • Is ‘plugin vs. no plugin’ , ‘open vs. closed’ a big deal for you ?
      And so forth…

      Unless you have a good feel about the nature of your requirement as well as the ‘load factor’ of the components within your product (see table above), making a choice to go with AJAX or Flash is like walking into a bull fight, blind-folded.

      It is important to understand where Flash and AJAX match, and where Flash and AJAX address completely different needs.

      The best way to do the onion ring comparison is to put it in ‘context’. So why not answer the above questions ?

      Is your browser going to be your only client ?

      RIA is not only about your ‘browser’ ! The Internet is not your browser either – it just so happens that a browser is an important tool in the overall environment. However, depending on what you are building, you may need a standalone client, which has all the richness of mashable-ness, web services interface etc. but does not run in the context of your browser. The entire concept of AJAX is that your ‘user experience’ is responsive right within the context of your browser. Flash on the other hand has a concept of a ‘standalone player’ or a ‘browser integrated plugin’. So before you choose one or the other, consider if using a ‘browser as a client only’ meets your business requirement. For example, a using a browser, you cannot have a server directly contact your client, unless the client first made an outgoing request to it (which is why in the AJAX world, you may be aware of techniques such as Polling, Comet, Piggybacking, to simulate such requirements). So if your application needs to go beyond a browser, AJAX may not be much of a choice.

      Do you expect voice and video to be a part of your service ?

      I get confused when people tell me they want AJAX to do voice and video. Voice and Video are CPU intensive operations – most voip solutions use at least some form of a codec which needs to be de-compressed in real time. In addition, if you add video to voice, there are further operations such as audio-video-lip syncing, and many other operations which adds to CPU utilization. In other words, if you are using voice or video, you need local power – it cannot be 100% server based ! For example, if you go to and see a video, the video is being streamed to your local flash-plugin which is an authorized plugin in the context of your browser, and that is doing the heavy lifting of voice and video encode or decode. If you use Wengo Viso to auto-magically insert a video call widget in your website, you are using your local computing power for capturing your video and voice, encoding it and transmitting it to the remote side and vice versa – courtesy of your flash-plugin. So while you think ‘there is no download’ , there is actually a ‘download’ – your flash-plugin that was packaged as part of your browser distribution !

      Simply put, if you need Voice or Video, Flash beats AJAX hands-down. Infact, AJAX really does not play in this space, since it really does not offer a voice or video solution – you pretty much need to craft the solution on your own, which could work, but would be rather onerous, and not as optimized as the flash voice/video experience.

      Also, you must have read about the much blogged about Flash-VoIP effort. I think it makes fabulous sense. If Adobe were to utilize its excellent distribution channels and bundle in a SIP UA and standard voice video codecs in the plugin, the entire browser world automatically gets voip and video enabled and writing web-widgets to activate that functionality becomes trivial. And like I said before, it effectively results in a 'no download' experience, because the download already happened one time before, as part of the 'platform update' and users had no ide
      a of it. So you can walk into a web-cafe, grab an available browser, and start voice/video chatting. Why would you need a local download of another 10MB voice chat software ?

      How important is security to your product, in a span of now to 5 years down ?

      It is commonly known today, that Javascript has several security issues that could be compromised by ‘script-kiddies’. This is of course a function of the maturity of AJAX vs. Flash. As I discussed in another article, this will change over time. But based on my assessment of security, it looks like Flash has a lead in security when compared to AJAX, at least today, and I think for the next 2-3 years. When I searched for flash-exploits, most of them were to do with buffer overflows, and less to do with malformed-script parsing attacks.

      So while Flash is ahead of AJAX here, you need to look into your crystal ball and see what you think your future holds for AJAX and weigh security along with other needs. For example, if you were making a solution like online office productivity, expect the browser as a client, and don’t think you are venturing into the ‘streaming intensive’ applications, AJAX may be a safe choice too.

      How important is ‘animation’ and ‘interactivity’ in your product ?

      If you are building a ‘virtual community’ or an ‘interactive social networking site’ which needs a lot of animation and fabulous transitions in real-time, you would notice Flash to be almost pre-dominant there, with new entrants also showing how AJAX powered interactive sites can also be made, for example, hive. But here is the catch, when you are building animation, you not only need to see the final product, but also need to ask the developers how simple it is to build such a solution. In addition, you need to keep a keen eye on the amount of ‘internet bandwidth’ you are consuming with this animation. The problem with AJAX is that while it has a benefit of ‘truly no plugin required’, it also means that whatever is needed, needs to be sent from the server to the client. If you run a network traffic monitor on graphics intensive solutions using AJAX, you would notice that there is a significant amount of backend downloading going on for supplying image frames as well as a large quantity of controlling logic code (JS, primarily) from the server to your browser. Solutions such as integrating SVG (Scalable Vector Graphics) into AJAX into a usable solution are too premature and only exist as proof that it can be done today. If you have developed in Flash, you would notice that ‘action script’ is only a small part of the overall solution. Flash offers a fabulous graphical animation studio, with easy to understand concepts of timelines, layers, frames and such which make animation really very simple. And the fact that you can control them all using actionscript, makes it a wonderful platform for creating interactive applications. And the other thing is when it comes to effective animation, I truly feel a plugin is a good thing. The server based model cannot beat local graphic-crunching, and the optimized flash plugin, which is written in native language, does a great job in rendering locally, within the frame of your browser if needed. And to boot, my personal experience has been that the file size, if written appropriately is really very small.

      For example, I spent last week reading about flash programming and then wrote a tiny ‘superman’ game for an interactive sidescroller show. It is buggy, but that is due to my own lack of time to make it robust – I just wanted to see how it worked , how simple it was, and how optimized it was. This flash game is a measly 9KB in size.

      Here goes:

      Or consider this fabulous new feature from Flash-8 that not only allows you to capture webcam detail, but process it as well within your actionscript to make 'motion detection' a reality using just a webcam. Apply this to an IBC application of a virtual chatroom. You are equipped with a web-cam, get into the virtual room, and bring your hand forward in front of the PC as a 'hand-shake' gesture. This is captured by your webcam, sent to the actionscript in the SWF that applies and appropriate algorithm to detect pixel changes in frames and evaluates this to be a handshake gesture, and your virtual online character automatically extends his hand to shake with the other virtual characters. And no, you are not using the Nintendo Wii. Just a webcam. Admittedly, detection motion vs. understanding motion are two different problem spaces, but Flash has the tools to make this happen. Like I said, when it comes to interactivity of this nature, Flash is simply fabulous.
      One may want to keep a tab on interesting efforts such as OpenLaszlo's Digital Life and similar. The technology is still very beta and one would need to see how it would scale and fit large content intensive applications over a span of time. I have personally not used OpenLaszlo, but I've talked to ISVs who have used it, and the feedback I got is it still very limited and has a far road ahead.

      Is making your IBC product available on mobile phones important ?

      Here is the fact: AJAX supported browsers for mobile phones are almost non-existant today. Doesn’t matter what Google search tells you on posts about the ‘impending arrival of AJAX for mobiles’. I’ve talked to countless mobile phone ISVs and the story is exactly the same:
      a) We don’t believe the browser is the only client
      b) Most browsers for mobile-phones are ‘limited’ today. Support for AJAX within the ‘limited’ browsers is a double limited !

      AJAX is in the radar , but Flash-lite is the reality there.
      What OSs do you need to support ?
      Theoretically, AJAX implementations should work on all OSes that have browsers that support all the required JS/DHTML/CSS tags needed. Reality would depend on how good current browser support is in those OSes and the plans they have for full compliance. On the desktop/server market, the predominant OSs are Windows, MacOS, Linux and maybe SunOS/Solaris (not any longer though, I think). On the terminal side, the main players are Symbian, Windows Mobile, BREW and some new penetration of real time Linux variants. Flash and/or Flash-lite is available for all of the above. AJAX requirements should also be available for all the server OSs listed above. But if you need support for esoteric/less used OSs, then there is no telling when Flash would be available for them (neither is there any telling whether full AJAX support would be available, but since AJAX is based on open specifications, an enthusiast could craft an AJAX engine (!) for them. So as far as 'guaranteed platform support and if not, let me write it myself' goes, AJAX wins. But if your business is in the mainline supported OSs, flash is fine too. Also, do note that competition is always healthy. Adobe recognizes the emergence of AJAX in certain niche applications, which could have otherwise been served by Flash too (like collaborative documentation, etc.), which is why they have made small entries such as Flex-AJAX bridge to ensure that users have options to work them together, but this is currently limited. So be rest assured th
      at a market leader can get as aggressive as needed to keep it's lead in the market. Adobe is no different.

      Is ‘plugin vs. no plugin’, ‘open vs. closed’ a big deal for you ?

      To be frank - I am often puzzled by this. Flash has a fabulous distribution channel. Almost every browser in the world has the flash plugin, and accepts signed updated from macromedia for flash player updates. Real time voice, video and animation needs local computing power. So what other solution is there, that is deployable en masse other than local clients (or plugins?). Infact, I think Flash has a great advantage here. Since the plugin is already a part of the browser, its ‘downloaded size’ doesn’t count. It reminds me of the argument of Firefox vs. IE. FF folks would always argue that the reason FF seems more sluggish than IE, is that Windows pre-loads parts of the IE engine as part of its OS initialization. So when the user clicks on the IE icon, only the remaining part needs to be loaded, unlike in FF, which needs to load the full she-bang, unless you use some pre-loader. Technically, I get it. From a user experience, I don’t think they get it. To a user, it does not count, if IE gets pre-loaded as part of the OS init. All he knows is that it resulted in a faster load time. The same holds true for Flash vs. AJAX. The plugin download just doesn’t count. If flash does a better job in local rendering of voice/video and animation, for AJAX solutions to play in the market, they need to compete and beat this by offer better performance, not more excuses. In addition, to do anything really useful in AJAX, you need more than just ‘bare-bones’ AJAX. You need to download and use one of the many ‘AJAX toolkits’. Depending on what they do, their size ranges from a few KB to a few mega bytes. So instead of downloading ‘flash player’, you are effectively downloading an ‘AJAX library’ (the innumerable .js script links in many AJAX pages). Alternately, you are generating gobs (hundreds and hundreds of lines) of JS/DHTML code which is being downloaded by your browser which was generated by some AJAX library you used for programming.

      Finally the ‘open vs. closed’ thing. Why is having source code so important? Yes, it is always better to control your destiny. I get that. But in this case, you need to see whether the APIs exposed by flash are limiting you or not. If not, then you shouldn’t be complaining. Also,’open source’ may be important for you for cost purposes. While Adobe distributes the flash and flash-lite player free, they charge for macromedia flash 8, flash-cast and other development solutions. Remember that AJAX has freeware and commercial-ware too. It is all a function of ‘functionality vs. price’. You are the best judge for it.