Home > The Offive > Archives

Posts Tagged ‘api’:

Windows Sidebar Widget

October 13th, 2009 by Brian Michalski

I spent a few days last week re-acquainting myself with Windows Sidebar, a widget engine introduced in Windows Vista and carried over into Windows 7.  My goal was to create a Concerto widget similar in functionality to the screensaver so people who don’t use a screensaver as much could still get some Concerto content delivered locally.  While Windows Sidebar doesn’t support Windows XP natively,  having native support for Vista & 7 should be sufficient for now.

Luckily, there is no secret sauce behind widgets… not on Windows, not on OS X… they’re all just HTML which is really convenient for a web-based system like Concerto.  I started with a really simple design, copying almost all of the code to rotate content from Concerto mini-screen we introduced in our 1.9 update.  I had to tweak the javascript slightly to pull the XML/JSON from a different domain.  For some reason, jQuery’s AJAX methods couldn’t handle the cross-domain request so I had to switch to the manual method: Internet Explorer’s XMLHttpRequest.  It wasn’t very painful to substitute in for the .ajax call, and I was still able to use jQuery for all my selectors and iterators.

I got the widget working, but it kept freezing up on me in very strange ways.  The text in a div that displayed the content name would keep rotating, but the image above would freeze.  For the life of me I couldn’t figure out why this was happening, especially since the text rotation was setup to be handled when the image rotation had completed.  I decided to pull out my watch and see if the widget kept freezing at the same time, surprisingly it did.  I adjusted the time each image was to be displayed and tested again, measuring the same number of image rotations.  It seemed that after X image rotations the image’s ability to fadeOut, fadeIn, or have it’s src changed were getting stopped by some unknown process.  Time to fire up taskmgr where I could get a slightly better look at what was going on.

The memory used for the widgets (I had multiple open at a time) kept growing and growing which seemed to correlate with the sudden freezing of the image rotation.  I wasn’t totally surprised by the memory issues, the internal workings of jQuery’s chaining and binding have never been very clear to me.  While I don’t know the details, it looks like jQuery was attaching a completely new set of functions to each image when it was loaded.  Since there were functions attached to the image maybe it didn’t get garbage collected out of memory like it should… or maybe the duplicate functions activated some sort of nasty recursion chaining… I really don’t know.  I was a bit surprised we didn’t notice this earlier, since the same code was used on the Concerto mini-screen which was pretty much copy and pasted from the actual javascript used on our screens.  Internet Explorer, Firefox, and Chrome all showed a steady growth in memory when left on the mini-screen for a period of time.  We hadn’t noticed the leak before because all those big web browsers have much higher memory limits per tab, its not nearly as low as the allocation for 1 widget.  I also suspect we didn’t spend time running the mini-screen for a very long time.  The average person stays on that page for only a few seconds before clicking off to login, visit the wall, or download the screensaver, so stability over time wasn’t critical during the design phase.  Upon further inspection. it looks like we left out the line in the JavaScript from our screen code that destroys everything in the field….

Now the widget is ready to be passed off to someone with a bit more graphical design & CSS skill than I.  I suspect my background-color: red; will get stripped away in favor or something that flows better with Concerto.

You can check out the code here: http://dev.studentsenate.rpi.edu/svn/svn-senate/extras/concerto.gadget/

Tags: , , ,
Posted in Concerto | No Comments »

Concerto API Updates

July 15th, 2009 by Brian Michalski

I just wanted to write a quick post to let everyone know about a few recent changes to the Concerto API and, more importantly, how they can take advantage of them.

Concerto has a pretty simple API accessible via HTTP GET/POST requests which exposes content in Concerto that has been approved on one or more feeds.  Lists of content can be accessed by the feed the content is shown on or the user who has uploaded the content.  Individual content items can be accessed by their unique ID numbers in the system.  Don’t worry, its not nearly as scary as it may sound. (The again, I wrote it…)

Recently, we pushed some updates out to clean up the output from the API so its more compliant with the OS X screensaver and we added a JSON-P style callback function to help anyone pull our JSON data into their applications.  Behind the scenes, we’ve spent time working to improve response time for resized images… recognizing that with stronger caching schemes on our end we can provide better experiences for API end users… like people who visit the Union homepage.

Time for an exercise with the API.

The default format for exposing data from the API is RSS but we also support JSON data and two varieties of html to make it easy for everyone.  Let me walk you through a sample query we use pretty regularly at RPI.

I want to get content all the content that is currently showing on screens from the Service & Community feed at RPI, in an RSS format for my feed aggregator.

The first step is to figure out what feed id corresponds to the Service & Community feed.  You can figure this out by checking out the XML document returned by this query: http://concerto.rpi.edu/content/render/?select=system.  Looking at that document, I can tell that feed 1 is the Service & Community feed.

Since we want the content from feed 1 (Service & Community), we’ll be using the select_id=1 option.  Selecting by feed is the default selection type (as controlled by the select parameter), so we don’t have to do anything special to control that.  In addition, RSS is the default format outputted by the system… so no need to mess around with the format parameter either.  This query gets shorter by the second!  Right now were using select_id=1, so our query looks like this: http://concerto.rpi.edu/content/render/?select_id=1.

I want the stuff that was recently submitted up top, so I’m going to add the orderby=submitted option, producing http://concerto.rpi.edu/content/render/?select_id=1&orderby=submitted. Ta Da!  Query generation complete.

If we wanted to be extra stable, we could lock in the API version by adding api=008 leaving us with http://concerto.rpi.edu/content/render/?select_id=1&orderby=submitted&api=008.  This step certainly isn’t necessary, and should probably only be used for a mission critical application or something that you don’t ever want to modify again.  Locking in the API version like this mean that if the Concerto team changes the defaults or the output formats around, I’ll still be getting the same data.

If you’re interested in reading more about the API, check out the documentation on Flagship: http://documents.studentsenate.rpi.edu/documents/show/77.  Also, if you have any suggestions, we’d love to hear them!

Tags: ,
Posted in Concerto | No Comments »

Screensaver Win!

July 13th, 2009 by Brian Zaik

Major props to Mr Michalski tonight for finishing an alpha version of a Windows screensaver using the Concerto API. The screensaver works natively on any modern Windows machine and, according to Brian, caches content locally. Win!

Once we clean up the Windows release, native screensavers will be available for both the Windows and Mac platforms. This is a big part of our strategy with Concerto to increase the number of active and passive methods through which people experience Concerto. Our hope is that doing so will increase the overall value of the entire network, since people at RPI will have more complete access to all of the messages on the system, even when their computers are idle. By having passive displays showing Concerto whenever nobody is using them, we make Concerto more pervasive across campus.

Plus, we seem to have at least a few starting customers…more on this soon. In the meantime, I have a YouTube video of Windows and Mac machines showing their respective screensavers.

Tags: , , , ,
Posted in Concerto, Cool Stuff | No Comments »

Windows 7 + RSS = PC Users finally getting some Concerto Feed Action…

July 10th, 2009 by Haris Khan

Well, Hello. It seems like this is my first post on this blog, first of many I hope. I usually leave Brian Zaik to the blogging as he seems to enjoy it very much so. For the first time I have something to say that has not been a collaboration with him.  Now don’t get too excited, it’s nothing too special, just a couple minutes of googling for an interesting effect.

For weeks I’ve seen Brian Zaik and August Fietkau have a RSS Screensaver. While Brian Michalski is developing something for us PC users, I grew impatient (as I always do). So I found an alternative, a RSS Wallpaper. Now It may not be as flashy as the OSX RSS Screensaver, but it does the job well.

All you need to do is open up a Windows 7 .theme file and insert the following code.

[Slideshow]
Interval=30000
Shuffle=1
RSSFeed=http://signage.rpi.edu/content/render/?select_id=1&range=all&type=graphics

A couple things to note.
The range variable. Possible values are -> all, future, past,live. Pretty self explanatory.
The select_id variable. This is just an integer value correlating to a Concerto feed. (1 is service and community)
The type variable. We want graphics here, Text isn’t going to be very useful as a Desktop Background.

Tags: , ,
Posted in Concerto, Cool Stuff | 1 Comment »

OS X RSS Picture Screensaver

June 28th, 2009 by Brian Michalski

I’ve been working on getting the RSS that Concerto provides via its API to be as compatible as possible.  Adding media RSS support seemed pretty straightforward and enabled us to do cool thing with some RSS visualizers like Cooliris and Google’s Photo Screensaver, but the built in OS X RSS Picture Screensaver never worked with any of our generated feeds. Feeds from Picasa, NASA, Flickr, and alike all worked well in OS X so I tried copying and pasting different formats to no avail.  It seemed no matter what I did, substituting the urls for our images crashed the feed.

Turns out, the file extension is important to the OS X screensaver.  Since the Concerto API is self-contained, it links back to itself to render images in various sizes.  The PHP script that handles the requests responds just like an image with a correct mime-type, some caching headers, and valid image data.  Calling this ‘index.php’ with the GET parameters (like index.php?&select=content&select_id=2911&format=raw) makes the screensaver display “The feed you have selected doesn’t have any pictures” or something like, because it thinks all the feed has is PHP files.  While it does only have PHP files, those files are outputting image data… not HTML, JavaScript, or text.  Maybe this is the quick way Apple avoids downloading files that it doesn’t want to handle like a doc, mov, etc… but the media:content field clearly has a mime-type parameter describing the mime-type of the content.

The solution I came up with: use mod_rewrite and a .htaccess file to send all requests in the API directory to index.php.  That way, I can link to something like image_2911.jpg and index.php will get to handle it like it is suppose to.

I can’t take all the credit for finding this bug, August directed me towards the file extension area… I was thinking it was more related to the image headers.

Tags: , ,
Posted in Concerto | 1 Comment »