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 >
