camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruno Borges <bruno.bor...@gmail.com>
Subject Camel Social component 'PoC' ready
Date Thu, 30 Sep 2010 19:08:28 GMT
Hadrian, remember the talk we had on ApacheCon 2009?
I know I took almost a year to have this thing done. Sorry for taking so
long! But here it goes.

I just want to state that Neociclo <http://www.neociclo.com> supported me a
lot on achieving this.
Not only we were able to code the Camel
OFTP<http://accord.ow2.org/odetteftp>component but now also I had time
and motivation to finish this component.

*Camel Social*
http://code.google.com/p/camel-social

The component is a PoC to poll social stream path in a uniform way from
social networks.

Some features:
- supports OAuth
- supports Basic Auth (wrapped by a OAuth credentials object (token =
username, secret = password)
- supports uniform SocialData (a unique id and the data itself)
- supports skip read social data (saves unique id for future polling and
skip them)
- supports custom social providers (just implement a SocialProvider)
- supports Twitter out of the box
- has Facebook and Foursquare classes ready to be implemented
- supports RateLimitExceededException to sleep consumer thread for a while
- supports session/non-session aware social providers
- supports social data producer on social stream path

*In a nutshell: *
from("social://twitter/public?skipRead=true&delay=5000")
.transform(xpath("//status/text/text()").stringResult())
.process(new Processor() {
*public void* process(Exchange arg0) *throws* Exception {
System.*out*.print(arg0.getIn().getHeader(SocialHeaders.*SOCIAL_DATA_ID*) + ":
");
System.*out*.println(arg0.getIn().getBody());
}
});

*How it works:*
- there can be only one pair of OAuth consumer token and consumer secret
(from client application) per endpoint
- OAuth is not required but recommended because of data fetch rate limits
(150 requests per hour on Twitter; 350 if "OAuthed")
- endpoint can have user oauth token/secret. In this case, it will poll
data. Otherwise it will work as event-based consumer
- exchanges going to this endpoint's producer with OAUTH header user's
token/secret and POLL_STREAM header to true will fire consumers to poll data
for that user
- exchanges going to this endpoint's producer with SOCIAL_DATA header to be
updated will require user's OAuth either specified on the endpoint or within
message headers
- endpoint specifies the social (stream) path. For example, in Twitter
provider there's support for user's home timeline and the public timeline.
"social://twitter/home" or "social://twitter/public"
- the provider must be able to return unique social data from the requested
social path
- social data is retrieved as is from the social network and can be
retrieved on message body, processed either by XPath (case of
Twitter/Foursquare provider) and JSON (case of Facebook)

*Things to consider*
- must the component require providers to present social data on unified
format? (twitter can provide xml/json/rss; facebook provides only json)
- must the one component's endpoint be able to stream social data for
different client's oauth token/secret? Like it does per user

*What's next?*
- consider to move this component to Camel trunk
- consider to have main social network providers (Twitter, Facebook,
Foursquare, Orkut, Buzz)
- optimize the data fetch process (take a look at AbstractTwitterPath)

Now, I definitely need some help on this to provide better support for
different social networks and social paths.
Anybody interested?

Cheers!!

Bruno Borges
www.brunoborges.com.br
+55 21 76727099

"The glory of great men should always be
measured by the means they have used to
acquire it."
 - Francois de La Rochefoucauld

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message