Yahoo Pipes is really smart mashup engine, which only giant Yahoo can afford to offer. I thought it's great service because it had democratized mashup a little more than before. But I became very excited when I noticed they are actually offering browser-direct external connectivity. Yes it's known as JSONP.
This is a simple pipe, provided by http://kentbrewster.com/badger, which accepts RSS URL input and generates output in JSON(P) format.
http://pipes.yahoo.com/pipes/zIQi0Iy72xGJ3NMhJhOy0Q/run?_render=json&s=http%3A%2F%2Fpersonalized20.blogspot.com%2Ffeeds%2Fposts%2Fdefault%3Falt%3Drss&_callback=handleFeeds
Test JSONP from Here.
Sunday, February 25, 2007
Saturday, February 03, 2007
Salesforce.com AJAX Toolkit and Firebug
Now I'm a salesforce.com's employee, recently using AJAX Toolkit so much often. Manoj Cheenath's AJAX Tools is really cool, but sometime I need some instant way to access Apex API from browser.
This is a bookmarklet to load salesforce's AJAX Toolkit on demand. Register this link to your browser's bookmarks.
load AJAX Toolkit
While you are in Salesforce.com's instance (I mean in *.salesforce.com), click the registered bookmarklet. Then open your firebug (or any other javascript shell) and put this into console.
You can connect Apex DB and inspect data anytime.
This is a bookmarklet to load salesforce's AJAX Toolkit on demand. Register this link to your browser's bookmarks.
load AJAX Toolkit
While you are in Salesforce.com's instance (I mean in *.salesforce.com), click the registered bookmarklet. Then open your firebug (or any other javascript shell) and put this into console.
sforce.connection.query('SELECT Id, Name FROM Account')
You can connect Apex DB and inspect data anytime.
Thursday, October 26, 2006
JSONRequest by Douglas Crockford
Douglas Crockford is now considering a new native JavaScript Object. It's called "JSONRequest", like XMLHttpRequest.
http://ajaxian.com/archives/jsonrequest-proposal
I read the proposal a little, and found that it is eliminating cookie information in its request header.
http://www.json.org/JSONRequest.html
By ignoring cookies, this new crossdomain request approach might become safe, but on the other hand it throws aside a chance to enable personalized mashup. For example, if you wish to embed your e-mail inbox list in your favorite portal service, JSONRequest can't do that because they won't carry any cookies.
I think it might be better to have opt-in mechanisms for both remote services and end users. When considering that almost all ajax applications are now regarding JSON as only in the same domain, so opt-outing (like referer-based JSONP access control; this technique is used here!) is rather unsafe in this case.
Anyway, this is a new proposal, it may take some years to be embedded in almost all our browsers. I hope this opinion could reach him (or some communities) in some way or other.
http://ajaxian.com/archives/jsonrequest-proposal
I read the proposal a little, and found that it is eliminating cookie information in its request header.
http://www.json.org/JSONRequest.html
JSONRequest does not send or receive cookies or passwords in HTTP headers. This avoids false authorization situations. Knowing the name of a site does not grant the ability to use its browser credentials.
By ignoring cookies, this new crossdomain request approach might become safe, but on the other hand it throws aside a chance to enable personalized mashup. For example, if you wish to embed your e-mail inbox list in your favorite portal service, JSONRequest can't do that because they won't carry any cookies.
I think it might be better to have opt-in mechanisms for both remote services and end users. When considering that almost all ajax applications are now regarding JSON as only in the same domain, so opt-outing (like referer-based JSONP access control; this technique is used here!) is rather unsafe in this case.
Anyway, this is a new proposal, it may take some years to be embedded in almost all our browsers. I hope this opinion could reach him (or some communities) in some way or other.
Monday, October 02, 2006
Yahoo BB Auth
Recently Yahoo! U.S. introduced an api which enables other developers to access their users' identity.
They call it "Browser-Based Authentication", and abbreviation is "Yahoo BB Auth".
http://developer.yahoo.com/auth/
I found that the naming was confusing, especially to Japanese Yahoo! users. Japanese telecom company Softbank and Yahoo Japan already branded their ADSL service as "Yahoo! BB". If you search "Yahoo BB", almost all entries are saying about this broadband internet service (currently). This implies that branding officer in Yahoo is not aware of their local services fully.
Anyway, This kind of service is interisting, and sounds nice to me. Google has already released its account authentication api. Maybe Flickr is the first (AFAIK) to open this kind of external access. This feature would be another must for future web 2.0 services.
But for the people who are moving ahead Liberty Alliance, or User-Centric Identity, this kind of movement might be unwelcome. Dick Hardt, CEO of Sxip, is saying "Yahoo/Google is deepening its identity silo". He says they aren't learning from the failure of MS .NET Passport.
User-centric, or distributed identity system is nice. I love it. But I'm afraid that the lack of this might not have been a main reason of the .NET Passport's failure. Currently it seems that users are not so unconfortable with their service, and developers are delighted with it. Who stops this opening movement of identity access, even if the api is a proprietary one? Because their service itself is absolutly proprietary, developers will not so be angry if the api is proprietary.
They call it "Browser-Based Authentication", and abbreviation is "Yahoo BB Auth".
http://developer.yahoo.com/auth/
I found that the naming was confusing, especially to Japanese Yahoo! users. Japanese telecom company Softbank and Yahoo Japan already branded their ADSL service as "Yahoo! BB". If you search "Yahoo BB", almost all entries are saying about this broadband internet service (currently). This implies that branding officer in Yahoo is not aware of their local services fully.
Anyway, This kind of service is interisting, and sounds nice to me. Google has already released its account authentication api. Maybe Flickr is the first (AFAIK) to open this kind of external access. This feature would be another must for future web 2.0 services.
But for the people who are moving ahead Liberty Alliance, or User-Centric Identity, this kind of movement might be unwelcome. Dick Hardt, CEO of Sxip, is saying "Yahoo/Google is deepening its identity silo". He says they aren't learning from the failure of MS .NET Passport.
User-centric, or distributed identity system is nice. I love it. But I'm afraid that the lack of this might not have been a main reason of the .NET Passport's failure. Currently it seems that users are not so unconfortable with their service, and developers are delighted with it. Who stops this opening movement of identity access, even if the api is a proprietary one? Because their service itself is absolutly proprietary, developers will not so be angry if the api is proprietary.
Friday, September 01, 2006
JSONP Private Calendar Mashup with Simile Timeline
I've created interesting demo to show how Personalized Web 2.0 services can be used in mashup application.
http://www.geocities.jp/stormriders999/timeline.html
I'm using MIT Simile Timeline for dynamic user interface.
You'll see that your own private schedule data in Google Calendar is mashuped, only if you granted us to acess them.
Yes, it is actually personalized service for you.
http://www.geocities.jp/stormriders999/timeline.html
I'm using MIT Simile Timeline for dynamic user interface.
You'll see that your own private schedule data in Google Calendar is mashuped, only if you granted us to acess them.
Yes, it is actually personalized service for you.
Subscribe to:
Posts (Atom)