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.ib...@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.bor...@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 >>
