Hi there, I've done some work on this but I'd like to know a couple things now:
Should I branch from master and you take care of cherry picking? What language level should I use? Can I go with Java8? Does it need to be 100% backwards compatible with the existing component? Some of the headers in the current impl can be improved IMHO but current usage would break if I changed them arbitrarily... is there a deprecation mechanism for headers? Advice on testing: Dropbox doesn't provide a testing module, is there a robust way to create a test harness? Some sort of record/replay tool perhaps? Best, Edoardo On Thu, 10 Nov 2016 at 14:56, Claus Ibsen <claus.ib...@gmail.com> wrote: > Hi > > Yeah you can take a look at how some of the dataformats does that as > they have out of bands streaming support with Camel's stream caching > http://camel.apache.org/stream-caching.html > > We love contributions, so you are very welcome to look into this and > provide a PR / patch. And to log a JIRA ticket. > http://camel.apache.org/contributing > > On Thu, Nov 10, 2016 at 11:50 AM, Edoardo Causarano > <edoardo.causar...@gmail.com> wrote: > > Hi all, > > > > just moved code from dev to testing and found that in real-life the > DropBox component blows apart in OOMs. Seems that it’s using plain BAOS > (sic) to buffer remote data which is not a particularly good idea when you > have no idea how big the files will be (or you’re pretty certain they’re in > the multiple GB range.) > > > > I’d rather not implement a client from scratch so I’d appreciate some > guidance on how to fix the existing camel-dropbox component to use > stream-caching. > > > > > > Best, > > Edoardo > > > > -- > Claus Ibsen > ----------------- > http://davsclaus.com @davsclaus > Camel in Action 2: https://www.manning.com/ibsen2 >
