After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 732748 - Need GIO based stream API
Need GIO based stream API
Product: gexiv2
Classification: Other
Component: interface
Other All
: Normal enhancement
: ---
Assigned To: Gexiv2 Maintainers
Gexiv2 Maintainers
: 794992 (view as bug list)
Depends on:
Reported: 2014-07-04 18:47 UTC by Michael Natterer
Modified: 2018-05-22 12:33 UTC
See Also:
GNOME target: ---
GNOME version: ---

Description Michael Natterer 2014-07-04 18:47:52 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.
Comment 1 Jim Nelson 2014-07-08 18:58:23 UTC
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.
Comment 2 Franz Dietrich 2018-01-14 12:04:10 UTC
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?
Comment 3 Jens Georg 2018-01-14 12:28:04 UTC
They are awful.
Comment 4 Franz Dietrich 2018-01-15 15:38:54 UTC
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.
Comment 5 Debarshi Ray 2018-01-15 15:41:42 UTC
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.
Comment 6 Franz Dietrich 2018-01-15 20:22:23 UTC
Ah ok now I get how to work with those! Thank you for the hint.
Comment 7 Jens Georg 2018-01-16 07:25:20 UTC
(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
Comment 8 Debarshi Ray 2018-04-05 14:14:04 UTC
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.
Comment 9 Jehan 2018-04-05 15:01:57 UTC
*** Bug 794992 has been marked as a duplicate of this bug. ***
Comment 10 Jehan 2018-04-05 15:22:37 UTC
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. :-)
Comment 11 GNOME Infrastructure Team 2018-05-22 12:33:41 UTC
-- 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: