Remove image-related features about seaweedfs

[chrislusf]

I think the goal is to make it useful and practical. Images are one of the major usage of weed-fs, and worth special treatment. And the image related features are not really complicating the code. Of course, we will unlikely add any more complicated features.

Having a plugin layer would be ideal.

[brejoc]

👍 for the plugin layer! That would put weed-fs on steroids!

[phal0r]

+1 for a plugin layer :)

[chrislusf]

Any idea on how to make the plugin? The Golang is statically compiled.

On Tue, Nov 11, 2014 at 9:45 AM, phal0r [email protected] wrote:

+1 for a plugin layer :)

—
Reply to this email directly or view it on GitHub
#8 (comment).

[ernado]

@chrislusf
Like heka.
Via lua (or js).

[chrislusf]

Very good to learn this!

Chris

@chrislusf https://github.com/chrislusf
Like heka.
Via lua (or js).

—
Reply to this email directly or view it on GitHub
#8 (comment).

[brejoc]

@chrislusf
Most of the times people seem to use net/rpc like packer did. But I guess this would only work if the plugins would also be go binaries. Since we are talking about plugins for image processing, I don't think limiting the plugin architecture to a specific language would be a wise decision. Piping data to a second process might be a better idea, since this would be language agnostic. Perhaps the pipe package might be of interest.
Named pipes might also be a way to go, but right now Go seems to lack support for it. But that might have changed.

[chrislusf]

An approach similar to heka's seems more feasible. We can provide an
interface to write/load/run go plugins compiled together with the original
source, and some default implementations. One of the implementation would
just use pipe for external processes.

For use cases requiring performance, it can go with a go implementation.

Chris

On Thu, Nov 13, 2014 at 12:17 PM, Jochen Breuer [email protected]
wrote:

@chrislusf https://github.com/chrislusf
Most of the times people seem to use net/rpc like packer
hashicorp/packer#1 did. But I guess this
would only work if the plugins would also be go binaries. Since we are
talking about plugins for image processing, I don't think limiting the
plugin architecture to a specific language would be a wise decision. Piping
data to a second process might be a better idea, since this would be
language agnostic. Perhaps the pipe https://labix.org/pipe package
might be of interest.
Named pipes might also be a way to go, but right now Go seems to lack
support for it. But that might have changed.

—
Reply to this email directly or view it on GitHub
#8 (comment).

[shen2]

A plugin layer will be nice.
There're a lot of image related features, such as ".webp" image compression, image resizing, exif info extraction, image format convert and image effect filters, etc.
Weed-fs cannot support all of these features, a plugin interface will make weed-fs more powerful.

[brejoc]

@chrislusf
Sounds good enough to me - as long as there is a way to pipe data somewhere else.