GNOME Bugzilla – Bug 732748
Need GIO based stream API
Last modified: 2018-05-22 12:33:41 UTC
There is currently no way to access "remote" files, as in whatever is behind an URI and accessible by a GIO stream. There should be API to read/write these based on GInputStream/GOutputStream.
I agree, gexiv2 would be well-served by GIO stream support. I should point out that gexiv2 does have its own notion of streams via gexiv2_metadata_open_stream() and gexiv2_metadata_save_stream(). Both of these use a ManagedStreamCallbacks struct which is a collection of callbacks for streaming. It wouldn't take too much work to use this system to operate via GIO streams. Under the covers, the ManagedStreamCallbacks is handed off directly to Exiv2, which is why this interface exists and not a more GLib-friendly one. A warning: this code came with gexiv2 when we first inherited it from the original author. I'm unaware of any program exercising this code path, so it's possible it's broken.
Additionally for the Python bindings it would be a really good Thing, as the gexiv2_metadata_save_stream() functions are not mapped. I would be very happy if someone could do this. As I have no experience in C and neither in mapping C to Python. What is the reason for not mapping the *_stream methods?
They are awful.
So this sounds a lot like - this will not be possible for the next 4 years :( How would I do the working on the metadata of remote files? Is the only possibility to: 1. copy to local, 2. edit, 3. save, 4. copy to remote? I mean doing this with streams involves probably the same amount of network traffic but would be a lot nicer on the code side.
If the remote location has a GVfs backend, and you can use GVfs, then the URI might have a matching path equivalent that works through GVfs' FUSE compatibility layer.
Ah ok now I get how to work with those! Thank you for the hint.
(In reply to Franz Dietrich from comment #4) > So this sounds a lot like - this will not be possible for the next 4 years :( No not really. I have started a branch for that, the issue is that Exiv2's stream API and GIO's stream api are not exactly matching
I found myself discussing this with Jens today, and it took me a while to remind myself why I was interested in GIO stream support in the first place. While GIO streams are more generic than GFile, in that they may or may not be backed by a GFile, all the code that I am aware of (ie., GNOME Photos, Nautilus, Tracker, etc.) currently end up reading and writing metadata to a GFile anyway. So, why would I be interested in streams anyway? The reason is that a GFile is only used to initiate an I/O operation by creating a GFileInputStream or GFileOutputStream. Once the stream has been created, the GFile no longer plays a role in the I/O operation. For example, when GNOME Photos needs to export an image to a file, it ends up with a GeglBuffer containing the processed pixels and a GFileOutputStream obtained from g_file_create or g_file_replace. It encodes the GeglBuffer as a JPEG or PNG to the GFileOutputStream, and then uses GExiv2 to copy the metadata over. If GExiv2 supported GIO streams, then I could rewind the GFileOutputStream and feed it to GExiv2. Since that's not possible, I have to carry both the stream and the GFile around in my code, so that once I am done encoding to the stream, I can use the GFile's path to copy the metadata. That's why even if something is ultimately reading or writing to a GFile, a purely path or URI or GFile based API isn't as useful as one based on GIO streams.
*** Bug 794992 has been marked as a duplicate of this bug. ***
So we had our first issue on GIMP regarding the absence of a GIO-based API, which makes that GIMP lost metadata support for some files depending on the characters used. See bug 794949. It looks like there may be a bug in g_win32_locale_filename_from_utf8() (bug 795006), and if confirmed, fixing it would fix our bug, but this is still a limited solution. Since we already have a GFile, having a GExiv2 API working on GInputStream/GOutputStream would be much better, since GIO does all the ugly work with paths and we would not have to care about these at all. Well just to put some light on this bug, though I'm not bringing much. :-)
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gexiv2/issues/15.