Add Non-Gallery Handlers for Media Module #121
Comments
|
nice job! |
|
2 years later... The site http://gallery.calip.so is down and i can't find image handling in actual calipso code. Additionnaly, a note in roadmap for such feature request. Have any of you guys any help or started work for me in order to achieve an Image(s) module ? I already have some sniplets for storing binary in mongo, and to handle HTTP native file transfert with express. |
|
Where is there a link to gallery.calip.so? I ported the calip.so site to nodejitsu, but I might be missing pieces. Recently I fixed /dox and /repo. On Sep 15, 2013, at 10:53 AM, nka11 notifications@github.com wrote:
|
|
The url appears into the present issue description. I dont need the s3 file handling, i'm thinking about site own storage for Have you some guidelines in order to help me to write a module for calipso
|
|
I like the idea of aloha media. The reason I went with s3 was that I wasn't sure whether the mongo grid store is grown up enough. Using blobs inside of a database containing images may work, but you can't stream those requiring them to be stored in the file system or in memory. That was a little bit of a concern, but I guess if they are not huge it's ok. Using s3 allows you to store things like movies and such on s3 and use the assets module to proxy the http stream directly from s3. Let me know what kind of use case you have? Small images, just icons and site decorations or real media storage. Because if you're using a nodejs deployment system like jitsu or heroku you can easily push images, obviously you can't post them from something like an iphone. I think there it's a good idea in any case. On Sep 15, 2013, at 11:23 AM, nka11 notifications@github.com wrote:
|
|
Ok I see the point for s3 and the problem for handling streaming, it's ok. Of course, my use case is about small contents like images and decorations. The user/client don't want an additional service and just use aloha, drops it's image from file explorer in an aloha-editable and then it shows, with tooling. In the background, it's (can be resized and) uploaded to the server and stored in db, maybe (automatically) declined in several resolutions (optimized for several uses : thumbnail, preview, full-screen, full-size). I know how to do all that, it's implemented in some of my projects. For optimisation purpose, mongodb file content could be duplicated in a file/memory cache or in a frontend reverse proxy. |
|
had a look on s3 plugin... Thought : have a multi-valued property-tuple type "Attachments" with an attachment-type (asset/native), and other fields depending of attachment type (For example : file-name, file-data and content-type for native, file-store, file-url and content-type for asset) |
|
You don't need a custom field module unless you want to support images as a Sent from my iPhone On Sep 16, 2013, at 2:44 AM, nka11 notifications@github.com wrote: Ok I see the point for s3 and the problem for handling streaming, it's ok. Of course, my use case is about small contents like images and decorations. The user/client don't want an additional service and just use aloha, drops I know how to do all that, it's implemented in some of my projects. For optimisation purpose, mongodb file content could be duplicated in a — |
|
That's not a bad idea. Make a local storage mode to store the file into the Sent from my iPhone On Sep 16, 2013, at 3:57 AM, nka11 notifications@github.com wrote: had a look on s3 plugin... Thought : have a multi-valued property-tuple type "Attachments" with an — |
|
Ok then, two points : Handle media natively regarding the resource/node referencing it... I'm but A single 'tag' association within the content may fit for simple entities. For well described entities, i'll need more bindings : example : I will need some "Image" properties for some kinds of entities which will 2013/9/16 Andreas Richter notifications@github.com
Je soutiens les logiciels libres, j'adhère à l'APRIL |
|
Ah ok. So you need a custom field type which will query into the available Sent from my iPhone On Sep 16, 2013, at 7:45 AM, nka11 notifications@github.com wrote: Ok then, two points : Handle media natively regarding the resource/node referencing it... I'm but A single 'tag' association within the content may fit for simple entities. For well described entities, i'll need more bindings : example : I will need some "Image" properties for some kinds of entities which will 2013/9/16 Andreas Richter notifications@github.com
Nicolas Karageuzian — |
|
Well, sounds good. Let's start incrementally : 1 - provide a native storage module Does it sounds good to you ? Regards 2013/9/16 Andreas Richter notifications@github.com
Je soutiens les logiciels libres, j'adhère à l'APRIL |
The first actual working release of the media module is focused on photo gallery management (which may actually be better refactored later into a gallery module!). This is because my wife was pestering me to build her a good site (not facebook or google+) to privately host our photos.
An example is up here: http://gallery.calip.so.
So, we need to add:
.... anything else on future roadmap.
Clifton
The text was updated successfully, but these errors were encountered: