Head of Developer Experience & Relations at Hookdeck
I ve just recorded a Kwwik demonstration of a Twitter page using the Kwwika service versus the http://search.twitter.com page versus TweetDeck to demonstrate the speed of the Kwwika service.Here s a link to the SPA 2010 c...
Ian Sanders recently posted a great thought provoking blog article about business by-products . I won't go into detail, Ian's post does that, but it's basically about finding value in things that aren't your key business focus but what you just have to do, day to day, in order to run your business or do your job. I've just this minute finished a Skype chat with a work colleague. As I was having the chat I realised that the conversation we were having had real value. It was a really good question to be asking and that if I didn't record this conversation now that I'd probably lose it and the potential value would be lost.
Update: Hang on a minute. You've not explained what Kwwika is! In a really informative chat using Nurph , which has been really useful in getting feedback, it was pointed out to me by @rythie and @NeilCauldwell that I need to explain what problem Kwwika is trying to solve before asking what the API should look like.
This post is going to be short and sweet. Short because Fiddler makes working around this problem so simple. And Sweet because I think this is really powerful and will allow you to develop applications that show why cross domain access, in some situations, should be allowed. In my last...
Cross domain requests (also known as Cross Origin Resource Sharing ) can be made using JavaScript without trickery, as far as I can tell, in Firefox 3.5 , Safari , Google Chrome and Internet Explorer 8 . This is done with all browsers except IE8 using a standard XMLHttpRequest object. The only thing required to notify the browser that JavaScript is allowed to make this request is for the server to send a Access-Control-Allow-Origin response header. Internet Explorer 8 uses an object called XDomainRequest and requires the same HTTP header. If the value of the header is then requests are allowed from all domains. You can be more restrictive if required.
Real-Time Web! Real-Time Web! Real-Time Web! Like me you may well be fed up of hearing and seeing this term. However, I'm guessing that you'll be fed up for a different reason to me. I'm actually very excited about the real-time web (I'm sure you'll have noticed) but I want to see it used as more than just a buzz term. I want to see real-time used in the true sense of the term - to mean that something has happened within the last few milliseconds. I want it to mean that the tweet you are reading, the picture you are viewing, the status update you are reading, the event you are being notified of is happening NOW .
I'm doing my best to keep up to speed on any news related to the real-time web. I follow interesting people on Twitter who tweet out links, I subscribe to RSS feeds and I've got Google Alerts set up on a number of phrases. Since I'm doing all this work I thought it would be a good idea to start sharing it by publishing the findings in an occasional summary blog post. I generally don't like blog posts which just say "this is an interesting article" but sometimes, if it raises awareness of good articles, it can be useful. Hopefully it will be. I tend to first post the links on the Real-Time Web Software and Technologies LinkedIn group so if you are interested on getting the news as I find it, or contributing your own real-time web finds then please join the group . Also feel free to Tweet at me or contact me via the website if you find anything interesting and relevant.
I've just come across William Vambenepe's blog and an article called " Waiting for events (in Cloud APIs) " where he discusses how an event system is missing from cloud vendor APIs. With my interest in Comet I straight away thought of this as a solution to the notification requirement and it's interesting that the article goes on to talk about subscription management and then moves on to thinking about the delivery mechanism which are all key aspects of a good comet implementation: How do you deliver notifications? Do you keep HTTP connections open through tricks similar to how self-updating web pages work (e.g. COMET, long polling and soon WebSockets)? Or do you just provide a listener endpoint to which the notifier tries to connect (which, in the case of public cloud deployments, means you need to have a publicly-addressable listener, but hopefully not on the same Cloud infrastructure). Do you use XMPP? AMQP? Email? Can I have you hold my events and let me come pull them?
According to this article by Read Write Web, Bing have exclusive access to the data created by Facebook user status updates and Google have access to the data from Facebook fan page updates. It's interesting to see that this data is so highly valued that there is clearly a bidding war over access to certain types of data. Which is more valuable? As of today, Facebook Fan Page status updates will begin appearing in Google search results, according to a tweet by Google. The announcement means that we will begin seeing results from the nearly 3 million fan pages, but not from the more than 400 million users.
I've started building a list of cloud hosting vendors , including those offering platform as a service (PAAS) . I'm trying to get vendors to contribute but as yet haven't been too successful. I'll need to directly approach them over the next few weeks to see if they'd be willing to provide me with a few details. Update 27/02/2010: A good friend of mine found a website that lists all cloud vendors. Although it doesn't contain all technology specific information that I was looking for it's quite a comprehensive list and a good starting point. Check out cloudxl . You can still view my original list too: View the list