Add Non-Gallery Handlers for Media Module

[cliftonc]

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:

• Generic (e.g. non-gallery) media forms and screens.
• Hooks into content forms to enable drag / drop adding of images to content when editing it.
• Selection windows for media to insert into content.
• Security (this is more general really)

.... anything else on future roadmap.

Clifton

[wqli78]

nice job!

[nka11]

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.

[richtera]

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.
I am not sure what gallery.calip.so should point to? There is an assets module which can proxy s3 folders to be available as urls on the site.
This allows you to manage the assets using the assets module or any s3 compatible application. But the module needs some work to be cleaned up.
Thanks
Andy

On Sep 15, 2013, at 10:53 AM, nka11 [email protected] wrote:

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.

—
Reply to this email directly or view it on GitHub.

[nka11]

The url appears into the present issue description.

I dont need the s3 file handling, i'm thinking about site own storage for
image, integrated with aloha imahe plugin for administration.

Have you some guidelines in order to help me to write a module for calipso
native image(s) field ?
Le 15 sept. 2013 16:59, "Andreas Richter" [email protected] a
écrit :

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.
I am not sure what gallery.calip.so should point to? There is an assets
module which can proxy s3 folders to be available as urls on the site.
This allows you to manage the assets using the assets module or any s3
compatible application. But the module needs some work to be cleaned up.
Thanks
Andy

On Sep 15, 2013, at 10:53 AM, nka11 [email protected] wrote:

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.

—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/121#issuecomment-24472981
.

[richtera]

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.
Thanks
Andy

On Sep 15, 2013, at 11:23 AM, nka11 [email protected] wrote:

The url appears into the present issue description.

I dont need the s3 file handling, i'm thinking about site own storage for
image, integrated with aloha imahe plugin for administration.

Have you some guidelines in order to help me to write a module for calipso
native image(s) field ?
Le 15 sept. 2013 16:59, "Andreas Richter" [email protected] a
écrit :

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.
I am not sure what gallery.calip.so should point to? There is an assets
module which can proxy s3 folders to be available as urls on the site.
This allows you to manage the assets using the assets module or any s3
compatible application. But the module needs some work to be cleaned up.
Thanks
Andy

On Sep 15, 2013, at 10:53 AM, nka11 [email protected] wrote:

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.

—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/121#issuecomment-24472981
.

—
Reply to this email directly or view it on GitHub.

[nka11]

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.
As i'm discovering calipso, and i find it interresting, i'd like to add this feature here, but i guess i need a "Field" module dedicated to Image(s) (just like in drupal) to handle specific content type and link it as a multi-valued property of a Node.

For optimisation purpose, mongodb file content could be duplicated in a file/memory cache or in a frontend reverse proxy.
We talked about the opportunity offered by mongo to handle big content (over 1G documents) in an earlier discussion with @draftkraft , I think a mongo content store can work, it's just a client's choice (subscribe s3 or other cdn or prefer to keep control). Implementation has to provide both.

[nka11]

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)

[richtera]

You don't need a custom field module unless you want to support images as a
custom field inside of a content cistom field area. I don't thinks you want
it there. If you make a module similar to assets (i would call it
aloha-media) then you have access to mongoose and can store the content.
For retrieval you can use a url like /media/. You can add image tags
into the content to refer to them
Andy

Sent from my iPhone

On Sep 16, 2013, at 2:44 AM, nka11 [email protected] 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.
As i'm discovering calipso, and i find it interresting, i'd like to add
this feature here, but i guess i need a "Field" module dedicated to
Image(s) (just like in drupal) to handle specific content type and link it
as a multi-valued property of a Node.

For optimisation purpose, mongodb file content could be duplicated in a
file/memory cache or in a frontend reverse proxy.
We talked about the opportunity offered by mongo to handle big content
(over 1G documents) in an earlier discussion with
@draftkrafthttps://github.com/draftkraft, I think a mongo content
store can work, it's just a client's choice
(subscribe s3 or other cdn or prefer to keep control). Implementation has
to provide both.

—
Reply to this email directly or view it on
GitHubhttps://github.com//issues/121#issuecomment-24491356
.

[richtera]

That's not a bad idea. Make a local storage mode to store the file into the
database
Andy

Sent from my iPhone

On Sep 16, 2013, at 3:57 AM, nka11 [email protected] wrote:

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)

—
Reply to this email directly or view it on
GitHubhttps://github.com//issues/121#issuecomment-24493821
.

[nka11]

Ok then, two points :

Handle media natively regarding the resource/node referencing it... I'm
okay with it

but

A single 'tag' association within the content may fit for simple entities.

For well described entities, i'll need more bindings : example :
foaf:person have a picture property which refers to an image, it (the
association) has to be stored somewhere in the db.

I will need some "Image" properties for some kinds of entities which will
reference an existing image (whatever it's container).

2013/9/16 Andreas Richter [email protected]

That's not a bad idea. Make a local storage mode to store the file into
the
database
Andy

Sent from my iPhone

On Sep 16, 2013, at 3:57 AM, nka11 [email protected] wrote:

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)

—
Reply to this email directly or view it on
GitHub<
https://github.com/cliftonc/calipso/issues/121#issuecomment-24493821>
.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/121#issuecomment-24503006
.

         Nicolas Karageuzian
  http://nico.karageuzian.com/

Je soutiens les logiciels libres, j'adhère à l'APRIL
http://www.april.org
Nouvelles de l'APRIL
http://planet.april.org/

[richtera]

Ah ok. So you need a custom field type which will query into the available
images or are you ok with pasting the image id and just storing a uuid?
Thanks
Andy

Sent from my iPhone

On Sep 16, 2013, at 7:45 AM, nka11 [email protected] wrote:

Ok then, two points :

Handle media natively regarding the resource/node referencing it... I'm
okay with it

but

A single 'tag' association within the content may fit for simple entities.

For well described entities, i'll need more bindings : example :
foaf:person have a picture property which refers to an image, it (the
association) has to be stored somewhere in the db.

I will need some "Image" properties for some kinds of entities which will
reference an existing image (whatever it's container).

2013/9/16 Andreas Richter [email protected]

That's not a bad idea. Make a local storage mode to store the file into
the
database
Andy

Sent from my iPhone

On Sep 16, 2013, at 3:57 AM, nka11 [email protected] wrote:

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)

—
Reply to this email directly or view it on
GitHub<
https://github.com/cliftonc/calipso/issues/121#issuecomment-24493821>
.

—
Reply to this email directly or view it on GitHub<
https://github.com/cliftonc/calipso/issues/121#issuecomment-24503006>
.

Nicolas Karageuzian
http://nico.karageuzian.com/
Je soutiens les logiciels libres, j'adhère à l'APRIL
http://www.april.org
Nouvelles de l'APRIL
http://planet.april.org/

—
Reply to this email directly or view it on
GitHubhttps://github.com//issues/121#issuecomment-24504203
.

[nka11]

Well, sounds good. Let's start incrementally :

1 - provide a native storage module
2 - then enable browsing in native storage and allow to include images
reference in content (img tag)
3 - build in a unique list of tuples (uuid, mime-type) of content/media
coming from any assets (native, s3 but maybe flickr, google image or youtube)
4 - provide the custom field providing media linking for entities

Does it sounds good to you ?

Regards

2013/9/16 Andreas Richter [email protected]

Ah ok. So you need a custom field type which will query into the available
images or are you ok with pasting the image id and just storing a uuid?
Thanks
Andy

Sent from my iPhone

On Sep 16, 2013, at 7:45 AM, nka11 [email protected] wrote:

Ok then, two points :

Handle media natively regarding the resource/node referencing it... I'm
okay with it

but

A single 'tag' association within the content may fit for simple entities.

For well described entities, i'll need more bindings : example :
foaf:person have a picture property which refers to an image, it (the
association) has to be stored somewhere in the db.

I will need some "Image" properties for some kinds of entities which will
reference an existing image (whatever it's container).

2013/9/16 Andreas Richter [email protected]

That's not a bad idea. Make a local storage mode to store the file into
the
database
Andy

Sent from my iPhone

On Sep 16, 2013, at 3:57 AM, nka11 [email protected] wrote:

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)

—
Reply to this email directly or view it on
GitHub<
https://github.com/cliftonc/calipso/issues/121#issuecomment-24493821>
.

—
Reply to this email directly or view it on GitHub<
https://github.com/cliftonc/calipso/issues/121#issuecomment-24503006>
.

Nicolas Karageuzian
http://nico.karageuzian.com/
Je soutiens les logiciels libres, j'adhère à l'APRIL
http://www.april.org
Nouvelles de l'APRIL
http://planet.april.org/

—
Reply to this email directly or view it on
GitHub<
https://github.com/cliftonc/calipso/issues/121#issuecomment-24504203>
.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/121#issuecomment-24504490
.

         Nicolas Karageuzian
  http://nico.karageuzian.com/

Je soutiens les logiciels libres, j'adhère à l'APRIL
http://www.april.org
Nouvelles de l'APRIL
http://planet.april.org/