> Yeah that is a missing piece in Camel. A lot of integration is file > based using FTP with all kind of zipped or not zipped files. > Would be nice to be able to zip/unzip directly from Camel instead of > must use script files. >
Very nice. commons-vfs is good. How would you suggest I go about creating a mega commons-vfs component ? Do I swing it off the file:// implementation ? As I mentioned I have freed the evening to work on this (in the hope that it will be easy /. (haha). Any suggestions for where to start ? I guess pinning down the vfs URL format, to me is quite crucial. vfs: ?? How would you see " polling a remote endpoint to an ever changing named ZIP file be handled ? eg: Each day a ZIP arrives .. sftp://u...@host://myfile-2009-01-08.zip, Given that vfs has the sftp capability in it .. would the URI look like (to capture the rolling day) vfs:zip:sftp://u...@somehost/downloads/myfile-${date:now:yyyy-MM-dd}.zip?consumer.delay=86400000 ? > > We could also consider adding our own component for TrueZip support to > be able to read/write archives, if commons-vfs doesnt pick it up. > Or just provide a patched version on a public repo, until they do put it in? Not ideal, but after all this is open source software :-)
