This is input-only, correct? Are there plans for output component(s) too? Don
On Thu, Sep 30, 2010 at 3: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 >
