Picture handling

(raven24) #1

Currently images are associated to posts, stored on the ‘home’ pod with only the link being sent to the recipients and there is not much more you can do with it, once it’s sent.

This means that image records are created in databases all over the network, and since (for now) the image records are sent separately from the post, this leaves the whole process open for network errors and anomalies.

What can we do to improve upon that?


Note: This discussion was imported from Loomio. Click here to view the original discussion.

0 Likes

(raven24) #2

I think it would be better if people could reuse their images as much as they want, once they’re uploaded and I suppose it would make sense to include the image data with the status message.
Either directly inside the federation XML (much like in #3940 ), or with a special markdown-like syntax for text-only embedding a ‘gallery’ of images - as much backward-compatible as possible, of course (maybe a combination of html-comments and markdown images).

Although in most manifestations, that would mean a protocol change - potentially breaking image federation with other servers or implementations…

0 Likes

(Flaburgan) #3

I think it can be a good idea to migrate image management to markdown. As MrZYX pointed, this can complicated how to display images, but the advantages are many :

  • the user will be able to place images where he wants
  • No more problem with federating images, the link is inside the post
  • No big federation protocol changes (both way can be used at the same time, if a old pod receive a message with markdown, it will display it correctly, and we can keep the old system and the new system together in the upgraded pod during a transition period (which can be very long, it’s not really a problem).
0 Likes

(goob) #4

I agree that it would be far better from a user perspective if once they have uploaded an image it is available to them to repost/reuse at a later date - if there is an ‘album’ repository of previously uploaded images available to the user. However, I have no idea what would be the technical challenges involved in making this work, so can’t say it should be done - but if it can be done, it would be a great feature.

0 Likes

(Flaburgan) #5

This bug is really annoying. @jonneha what do you think about the markdown solution ? We have to decide, this has to be fixed…

0 Likes

(Jonne Haß) #6

If we drop the logical reference in all database, how do we delete the associated pictures with a post?

0 Likes

(Flaburgan) #7

We can keep an image table, this table is not federated anyway, so it’s just about use markdown to display picture instead of use our html, nothing more.

0 Likes

(Jonne Haß) #8

And how do you decide which size to display? Currently we have the flexibility to display different sizes depending on where we want to display them in the UI, i. e. we can show a larger version in the single post view and a smaller one in the stream. And no, it’s not a good practice to just scale it down with CSS.

0 Likes

(Flaburgan) #9

I know it’s not a good practice to scale it using CSS, the stream will become really heavy if we do that. But this is already the case for images shared with markdown. I am not a specialist, but unify how we deal with pictures seems a good idea. And we want to keep markdown and the solution to put markdown everywhere keep compatibility with the older pods.

0 Likes

(Jonne Haß) #10

So I guess you also prefer to scroll a few pages then to have the current image viewer when a user wants to attach 10+ pictures?

0 Likes

(raven24) #11

I think inlining the associated image records with the post XML already is a big step towards making image federation more reliable.
If me manage to make an ‘image chooser’ for new posts to include already uploaded images we’d already gain a feature - like: “upload photo or choose existing image”
:wink:

0 Likes