Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

passthrough mode for :local #1

Open
ronen opened this issue Jun 4, 2012 · 0 comments
Open

passthrough mode for :local #1

ronen opened this issue Jun 4, 2012 · 0 comments

Comments

@ronen
Copy link
Owner

ronen commented Jun 4, 2012

It would be nice to have some sort of :passthrough => true option to Defog::Proxy.new(:provider => :local, ...) which would disable caching and proxying and directly serve up the actual files.

Rationale:

The current situation is that :local goes through the same caching mechanism as :AWS. This makes sense in particular for the common (i think) case that :local is being used in development as a standin for :AWS that is used production -- in this way development mimics the production behavior as closely as possible, and supports cache & synchronization manipulation.

But I've got a case where code that uses the Defog API to do some file processing on files stored in :AWS -- and it turns out in production i also want to occasionally do the same processing on files that originate on the client and aren't in AWS. Easy enough to do that by creating a Defog::Proxy using :local and it works fine -- except that it wastes time and space by making a proxy copy of each file and then synchronizing back. Would be nice to be able to skip proxying and act on the files directly.

Notes:

The :passthrough option would only make sense for :local. When enabled, things like :synchronize => false wouldn't make sense. (Ignore them? Warn? Error?) Also, without :passthrough, deleting the proxy file is equivalent to :synchronize => false, but if :passthrough were true deleting the "proxy" would really delete. This makes me think that without :passthrough, deleting a proxy file should instead either raise an error, or delete the remote file.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant