Parser for XMLTV format and SchedulesDirect data
Image via Wikipedia
For a long time now, I’ve been a paying customer of SchedulesDirect, and by that token their parent company Zap2it (now a Tribune Media Services company).
Recently, I’ve started publishing my own personal Electronic Programming Guide (EPG) here on BCmoney MobileTV in an accessible format:
BC$ EPG
One of the secondary goals of my MobileTV project has always been to be able to provide all XMLTV users a venue to easily access and conveniently plan/schedule their TV viewing via the web, on a variety devices (i.e. mobiles/tablets/desktop computers).
Soon I’ll be adding in a User Management feature that allows you to signup for SchedulesDirect and synch your account through BC$, and most importantly, protect your EPG and viewing data by your username and password (this is required to meet the SchedulesDirect usage terms and privacy policy).
I found that GET requests are not supported so technically the Tribune Web Service must still be following the SOAP 1.1 not SOAP 1.2 standard which specifies both GET and POST are acceptable as long as the SOAP request enveloppe is passed via URL.
Since that is not supported, you have to use POST and it also has to have the BASIC authentication information included in the header in the exact pattern:
Read the rest of this entry »
Resurrecting the Google SOAP API
Original Photo courtesy of Magicfantasy on Flickr: http://www.flickr.com/photos/manicfantasy/889984960/
I know what you’re thinking, Let Sleeping Corpses Lie right?
Well let me first start off by saying I am not a huge fan of SOAP or anything, in fact, I much prefer REST about 90% of the time. However, there are still some cases where a fully controllable SOAP API which simply lists results as XML wrapped in a SOAP envelope, is a better way of interacting with data; particularly when that data is updated less frequently and is larger in size. Seeing Google results as XML can make them easier to manipulate and exchange, oh and lets not forget, that XML is what the X in AJAX stands for anyway, though JSON is used interchangeably these days, if not more often. With the debate between the SOAP and RESTful crowd all but won by REST and its simplicity, lets go ahead and awake the sleeping dinosaur that is the Google Search SOAP API for experimentation’s sake. For a quick history lesson, in 2006 the headlines rang to the predictable tune of “Google Drops the SOAP“, which Google eventually responded to by effectively saying “move on” and former managers for Google’s SOAP APIs came out and explained Why SOAP sucks.
In choosing between web scrapping and using the new Search API, I’ve opted to go for the more advisable Search API approach. The wrapper code for the Google AJAX Search API was done in PHP, using a simple client/server implementation, and referring to an old archive of the SOAP API’s WSDL here:
http://bcmoney-mobiletv.com/google/GoogleSearch.wsdl (here’s a sample SOAP request)
Read the rest of this entry »
Integrating Data
Image via Wikipedia
An increasingly common problem on the web (not to mention Computer Science in general) is the integration of disparate data sources.
Whether those data sources are accessed via Web Services, APIs, databases, scraped-content, or even plain old flat files seems to be less and less relevant in comparison to the quick and efficient production, consumption and integration of the data itself.
For this reason, BCmoney will be launching a number of new products in 2009-2010, the early prototypes of which can be seen here:
- BC$ MobileTV – Video Repository (mashup of Freebase, IMDB, Wikipedia, YouTube, DailyMotion, Veoh, Blip.TV, MegaVideo & more…)
- BC$ MobileTV – Music Repository (mashup of Freebase, MusicBrainz, Wikipedia, MyPlaylistz, Last.FM, Blip.FM, LyricsWiki)
- BC$ MobileTV – News Portal (personalizable mashup of RSS news feeds from all over the web)
These represent a departure from the typical destination site by integrating data from various sources in dynamic, user-defined ways. Look for more continued developments in these and other aspects of the BCmoney MobileTV service in the near future!
Related articles
- The Most Popular API Pairings May Surprise You (programmableweb.com)
- 700 Social Mashups: Twitter and Facebook Reign (programmableweb.com)
- Listen Up, Shazam; Hundreds Of Rivals Are About To Bloom (paidcontent.org)
- Big data and open source unlock genetic secrets (radar.oreilly.com)
- OpenText to Unify Data with an Integration Center (arnoldit.com)
- Introducing Balloons: Free multimedia overlays for bloggers (zemanta.com)
- Jagimo! The Social Mashup Re-Launch (themactrack.com)
The Server-Side Proxy
Image via Wikipedia
The Server Side Proxy… oh how I despise thee.
It’s a technique which we wouldn’t have to utilize at all, were it not for Browser security restrictions (which are admittedly in place for a good reason, to save us from ourselves).
Problem
The Same-origin policy, also known as same-domain limitation.
Reaction
After IE4 and a number of other browsers had vulnerabilities revealed where Cross-Site Scripting (XSS) attacks were exploited to gain access to user data, jeopardize accessibility of, or otherwise vandalize popular Web Services and Web Applications, the Browser vendors got together and decided to lock down their browsers into a “sandbox”.
What is a sandbox you ask? In non-developer speak its just like you can find in public parks, a set of boundaries around a soft and malleable plot of land where you can play safely and fall down as much as you want without hurting yourself (or others). Even if you did decide to go on an all-out rampage, you could only at most hurt other people inside the sandbox. In geek speak, its a security mechanism for separating running programs whereby code is isolated to its own space in memory and/or its own path on the network. This effectively means your client-side code can’t make a request to any URL above its own path, let alone to an external Web Service or application.
Solution
BC$ (JS/xHTML/CSS) Web Framework
Collage of JavaScript frameworks.
(Photo credit: TripWire)
In light of the massive popularity of existing JavaScript frameworks such as Dojo, jQuery and the original one (as far as I’m concerned) Prototype.JS I’m releasing a heaping mass of code which I’ve accumulate over the past 3 years of consulting, tinkering, hacking, borrowing ideas, and learning in web development. I doubt that my own will ever reach the prolific popularity of the more popular frameworks, and even personally I’ve all but resigned to using jQuery or Prototype (depending on the problem); but I’m releasing it as a version 1.0 (Beta and FINAL release all in one) nonetheless, if only it may come in handy to someone, somewhere.
In fact, it’s a combination of scripts, snippets and one-off functions I’ve picked up from around the web (attribution give where required, and licenses repsected of course) or written myself to solve a particular need and summarizes the 20 most commonly requested features for a website, blog or web application that I have typically been asked to build as a freelancer or software development consultant:
- Security
- Validation
- Dates
- URL
- Cookies
- User-Agent
- I/O
- DOM
- CSS
- DHTML
- Images
- Flash media
- AJAX
- Web Services
- XML
- JSONp
- JSON
- CSV
- File Upload
- Controls
The code is available below:
-or-
Related Articles
BC$ = Behavior, Content, Money
The goal of the BC$ project is to raise awareness and make changes with respect to the three pillars of information freedom - Behavior (pursuit of interests and passions), Content (sharing/exchanging ideas in various formats), Money (fairness and accessibility) - bringing to light the fact that:
1. We regularly hand over our browser histories, search histories and daily online activities to companies that want our money, or, to benefit from our use of their services with lucrative ad deals or sales of personal information.
2. We create and/or consume interesting content on their services, but we aren't adequately rewarded for our creative efforts or loyalty.
3. We pay money to be connected online (and possibly also over mobile), yet we lose both time and money by allowing companies to market to us with unsolicited advertisements, irrelevant product offers and unfairly structured service pricing plans.