camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hadrian Zbarcea <hzbar...@gmail.com>
Subject Re: Camel Social component 'PoC' ready
Date Wed, 06 Oct 2010 19:01:08 GMT
Hi Bruno,

I still didn't have a chance to look at it but I promise to do it this week. One question
I have is if you are using opensocial for it or some other api?
I am very curious to see if there's any oauth integration as well. 

This is more certainly a cool component which opens camel to a whole new set of integration
scenarios.

Wait for my comments, thanks for the patience and many thanks for being an evangelist for
camel in Brazil !
Hadrian


On Oct 6, 2010, at 2:50 PM, Bruno Borges wrote:

> Thanks Claus.
> 
> The Twitter provider is, in my concept of "done"... done.
> 
> It can produce and consume tweets.
> 
> It is easily possible to implement with EIPS, a "retweet" route.
> 
> Next on my TODO is a Camel Processor to implement the ReTweet process (which
> requires some headers to be set).
> 
> 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
> 
> 
> 
> On Sun, Oct 3, 2010 at 1:30 PM, Claus Ibsen <claus.ibsen@gmail.com> wrote:
> 
>> Hi
>> 
>> Excellent.
>> 
>> I think it would make it easier for others to help out if we get one
>> social integration done and we have documentation and examples how to
>> use it.
>> You mention twitter is already in there. So it would be nice to have,
>> lets say, an Camel example application that uses twitter.
>> Then people can try it out.
>> 
>> But great and keep up the good work.
>> 
>> 
>> On Thu, Sep 30, 2010 at 9:08 PM, Bruno Borges <bruno.borges@gmail.com>
>> wrote:
>>> 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
>>> 
>> 
>> 
>> 
>> --
>> Claus Ibsen
>> Apache Camel Committer
>> 
>> Author of Camel in Action: http://www.manning.com/ibsen/
>> Open Source Integration: http://fusesource.com
>> Blog: http://davsclaus.blogspot.com/
>> Twitter: http://twitter.com/davsclaus
>> 


Mime
View raw message