Backend-Structure for Media

[CodedOre]

So, I have today started with an concept for the media classes, which can be found on the branch media-class.

However, I wanted to discuss the structure of these classes.

The backend has to met the following goals:

• Providing the main API for the frontend in the base class
• Allow for extending the base class to implement code for reading specific jsons in the platform namespaces.

Additionally, the media class should have sub-types for pictures, videos and gifs (and maybe audio for a certain platform?).

So, the first concept has the structure:

• A base interface for Media for the API.
• A second base interface for media sub-types, inheriting from the Media interface in Base.
• A abstract Media class in the platform, inheriting from the Media interface in Base.
• And a class for media sub-types, inheriting from the Media abstract class and the interface for the sub-type.

This seems to work and reach the goals, however I am not 100% convinced there could not be a better solution than this.

So, @IBBoard, would be great if you could take a look and comment on this.

[IBBoard]

and maybe audio for a certain platform?

I completed a Twitter developer survey the other day and they mentioned "spoken posts". So there could yet be a day when we don't just have tweet storms instead of blog posts, but we have podcasts presented as a sequence of tweets! 😮

This seems to work and reach the goals, however I am not 100% convinced there could not be a better solution than this.

I can't think of a better structure. "diamond inheritance" can sometimes get a bit messy, but I think we can keep it sufficiently consistent here that it will work (Backend.<Platform>.Media handles parsing and common stuff and Backend.<media-type> subclasses handle the type-specific content and widgets). And since each platform will be different in its JSON and how it loads images (e.g. Twitter DM images need an OAuth connection) then you need per-platform as well as per-type classes.

You might want a "load progress" event as well as "complete" so that progressive loads (or slow Internet connections) can get progress bars etc.

We might need preview dimensions as well as final media dimensions (e.g. if the thumbnail is cropped).

Are we assuming that preview_image is null until load_preview() is called and completes?

[CodedOre]

I completed a Twitter developer survey the other day and they mentioned "spoken posts". So there could yet be a day when we don't just have tweet storms instead of blog posts, but we have podcasts presented as a sequence of tweets! open_mouth

I was more referring to Mastodon, as they already have audio as a possible type for an Attachment.

Are we assuming that preview_image is null until load_preview() is called and completes?

Actually removed this property, I think it would be better to have this be a private field and allow load_preview to hand this out when already loaded.

[IBBoard]

Didn't realise Mastodon had audio attachments. But it makes sense that Twitter is copying someone 😁 I'm sure they're used far more sensibly than they would be on Twitter!

As for load_preview(), it's basically a caching async then - it either fetches and returns, or it returns the already cached version? Makes sense, and prevents that "Can I access the property? Do I need to call the load method? Should I call the load method anyway to make sure? Or will that break something? Or maybe make it download it again?" problem.

You might also need to look in to threading as well as just async. I don't know what you know (and I don't know how much depth I know!) but I'd seen some comments somewhere about async alone not being enough because it'll still occupy the main thread, whereas long-running and potentially intensive things like downloads should be pushed to a dedicated thread. Which is what Cawbird does now, but in the C code.

[CodedOre]

You might also need to look in to threading as well as just async. I don't know what you know (and I don't know how much depth I know!) but I'd seen some comments somewhere about async alone not being enough because it'll still occupy the main thread, whereas long-running and potentially intensive things like downloads should be pushed to a dedicated thread.

Actually, the GLib doc for Threads says its "unnecessary"...

But I have just pushed the change to use a GLib.Task, you might want to check it.

[IBBoard]

It looks like Cawbird is using the still-recommended part - g_task_run_in_thread(). I guess it comes down to whether everything that matters is "GLib functions, such as single GIO operations" or whether it's other operations that will make the UI unresponsive.

I think the problem comes in that the async function gets kicked off and uses the main thread when it's "idle", but if the user then wants to do something else while it's idle then it's now not idle because it's working on the async task. But I could be wrong. I've always just let async do its magic and not poked threads versus async much (especially in C-based languages).