Tag: proxy

I've updated DeliTag. Currently, it only supports Del.icio.us integration with Firefox. To enable broader compatibility, I'm actively seeking proxy scripts for SIMPY and SHADOWS.

I'm considering compressing Yahoo Search results from my proxy, as suggested in a Yahoo Developer Blog post. I'm unsure if it's easy, worthwhile, and where to implement it (client-side or proxy-side). I'll need to handle browsers without compression support. Any advice?

The related Wikipedia articles feature in AjaxTagger v1 is temporarily broken due to an update in one of the Yahoo Perl Proxy Scripts for AjaxTagger v2. I plan to fix it soon.

In part two of this series on the failures of my first AJAX application, I discuss how my initial plan to reduce bandwidth by having the client directly access third-party web services didn't work out. Due to cross-domain scripting issues in Firefox and IE 6/7, I had to implement proxy scripts on my server. This means all client requests now go through my server, increasing my bandwidth demands. While using a proxy server offers benefits like hiding security information (like Technorati developer tokens) and enabling data manipulation/request merging, it comes with the major downside of increased bandwidth usage and the need to create/maintain proxy scripts. I hope to support cross-domain data sources in the next version to mitigate these issues but acknowledge there might still be scenarios where proxy scripts are necessary.

I've just finished creating a proxy script that allows access to the Yahoo Content Analysis API Term Extraction service from any browser, bypassing cross-site scripting issues. It works by taking a POST request, forwarding it to Yahoo, and returning the XML response. The code (Perl) is included in the post, and I've successfully tested it with IE6, IE7, and Firefox. Feel free to email me if you have any questions.

This blog post introduces a Perl proxy script that leverages the Yahoo Related Suggestions API. Given a search term, the script queries Yahoo and returns a list of related search terms. This can be used to enhance search functionality by providing users with additional relevant search options. An example is given using the term "Kinlan" and the post links to a previous entry describing a proxy for the main Yahoo search API. The provided code snippet demonstrates how to construct the API call using LWP and CGI, requiring a valid Yahoo App ID.

This post, part 8 of a series about my first AJAX application, discusses my return to Perl programming after a year of focusing on C# and .Net. I needed to solve cross-domain scripting issues when calling a web service directly from the webpage. My solution involved proxying the request through a Perl script on my server, which also hid my developer tokens. I found Perl's libraries easy to use and effective for this task. Future plans include more Perl scripting to aggregate data from different blogs and web services, leveraging the proxy to combine multiple calls and enhance functionality. I also learned a valuable lesson about using "content()" methods for POST operations instead of the query string.

The Feedster API has potential, but it's unclear what its purpose is. It would be more useful if it allowed content searches and provided metadata about searches, such as the number of blogs or pages a term appears in. Additional features like showing top searches and providing search result counts could be valuable. The current API requires a private key, which necessitates a proxy script for security. A simpler authentication method like Yahoo's Application ID would be preferred. Despite some limitations, the ability to publish search results as an RSS feed is a nice feature.