Rate this:
Related
I'm a Senior Lecturer at The Open University, with an interest in #opendata policy and practice, as well as general web tinkering...
View all posts by Tony Hirst
Oh wow, this is groovy. I now take back all the non-programmistan propaganda I spread about Pipes! This is straight forward, and will serve as a nice hacked solution for aggregating ical feeds for UMW. You really are remarkable, the way you work through these solutions openly and meticulously helps me realize how much of what we do is that very process you narrate beautifully here. After this unbelievably helpful series of posts, you mmay have gotten yourself into an awkward position—because after this kind of response I may be trying it far more often :) Thanks Tony!
@jim It’s a pleasure “working” with you; the whole point about OUseful.info is that some of the stuff is useful to someone…everyone in the OU is “too busy” working on “big projects” to see where any of this could lead. Which makes you pretty much my only “user”. Maybe I need to rename the blog MUseful.Info, given that you do seem to be able to find a use for the some of the craziness I come out with;-)
(One thing to note on the “risk analysis” side – I’m not sure to what extent it makes sense to use Pipes in a production environment…?! ;-)
Frickin’ brilliant. I’m curious about one thing. I get how you aggregated the feeds using Delicious and Pipes. Those steps are relatively straightforward for someone who understands how those services work. What I can’t figure out is what made you think to filter your Pipes feed URL through TinyURL? Maybe I don’t understand what tinyurl does, but that step would never have occurred to me in a million years.
BTW, I used this to aggregate 10 separate calendars over at
http://www.ppmrn.net
.
Thanks!
“What I can’t figure out is what made you think to filter your Pipes feed URL through TinyURL? Maybe I don’t understand what tinyurl does, but that step would never have occurred to me in a million years.”
I’ve been playing with feed pipeline mashups for quite a time now, and have developed several superstitious beliefs over that time…;-)
There are a couple of problems that can arise relating to the handling of unescaped URIs passed as arguments to a webservice, particularly when it’s ambiguous as to which URI an argument applies to.
e.g. in service calls constructed according to the patterns
http://example.com/service?url=http://example2.com
or
http://example.com/service/url/http://example2.com
bad things can happen if the argument URL is not escaped and the example.com service has not been programmed defensively/to accommodate .
For example, is “arg1” or “arg2” an example.com or example2.com argument in the following cases?
http://example.com/service?url=http://example2.com?&arg1=foo&arg2=bar
http://example.com/service/url/http://example2.com?arg1=foo&arg2=bar
So sometimes, if you “defensively programme” a pipeline mashup, or notice a particular construction keeps failing, it makes sense to try something like
http://example.com/service?url=http://tinyurl.com/foobar23
Note that escaping gets problematic when you have a long pipeline if things aren’t escaped. For example, how do you read this?
http://example.com/service?url=http://example2.com?arg=foo&arg2=bar&url2=http://example3.com/service?arg=bar&finalArg=true
Who “owns” arg2, url2 or finalArg? example.com/service, example2.com/service or example3.com/service?
In some webservices, it may be that there is a limit to the length of a URI that is being passed to the service, in which case reducing the length of the URL you are passing is sometimes worth a try.
Remember that I play around the pragmatic, scruffy end of the web, too, trying to just get things working for proof of concept demos, and looking for workarounds for the bits that don’t quite work properly yet;-)
Hey, nice blog here. I’ve been looking at getting this to work for some time, and the tip about tinyURL is a good one. I think I tried FeedBurner or some-such. Anywho. The hangup with getting this deal to work still boils down to how Yahoo Pipes fails to handle recurrent ical events out of gCal. See
this discussion (
http://tinyurl.com/bw8p39
), and let us all know if you can solve it.
I investigated why with pipies generated iCal Feeds doesn’t work with iCal (the Mac OS X Application)
I found out I has to to with the HTTP headers:
Orinal header from pipes, which iCal doesn’t accept:
HTTP/1.1 200 OK
Date: Fri, 03 Jul 2009 14:18:46 GMT
P3P: policyref=”http://p3p.yahoo.com/w3c/p3p.xml”, CP=”CAO DSP COR CUR ADM DEV TAI PSA PSD IVAi IVDi CONi TELo OTPi OUR DELi SAMi OTRi UNRi PUBi IND PHY ONL UNI PUR FIN COM NAV INT DEM CNT STA POL HEA PRE GOV”
Content-Disposition: attachment; filename=sotm09_test_2.ical
Connection: close
Transfer-Encoding: chunked
Content-Type: text/calendar;
Header from a ical file with identical content form my webserver which works:
(i got this file via wget
http://pipes.yahoo.com/pipes/pipe.run?_id=pr_5FtNn3hGh95CjY1g5sQ&_render=ical
)
HTTP/1.1 200 OK
Date: Fri, 03 Jul 2009 14:20:48 GMT
Server: httpd mod_perl/2.0.4 Perl/v5.10.0
Last-Modified: Fri, 03 Jul 2009 14:09:47 GMT
ETag: “601d4-1162-46dcdb57660c0”
Accept-Ranges: bytes
Content-Length: 4450
Connection: close
Content-Type: text/calendar
The differences is the missing Content-Disposition: attachment; filename=sotm09_test_2.ical which confuses iCal.
To test this conclusion create php file on your webserver with the following content:
Than add the url of that file to iCal and it works
I posted my conclusions also at
http://suggestions.yahoo.com/detail/?prop=Pipes&fid=151976
Enter your email address to subscribe to this blog and receive notifications of new posts by email.
Email Address:
Privacy & Cookies: This site uses cookies. By continuing to use this website, you agree to their use.
To find out more, including how to control cookies, see here:
Cookie Policy