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 761515 - Redo the metadata-manager
Redo the metadata-manager
Status: RESOLVED OBSOLETE
Product: gedit
Classification: Applications
Component: file loading and saving
unspecified
Other Windows
: Normal enhancement
: ---
Assigned To: Gedit maintainers
Gedit maintainers
Depends on:
Blocks: 761138
 
 
Reported: 2016-02-03 18:48 UTC by Sébastien Wilmet
Modified: 2020-11-24 09:58 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Sébastien Wilmet 2016-02-03 18:48:01 UTC
Currently, gedit-metadata-manager stores only the metadata for the 50 most recently opened files. We can do better than that.

To better scale, here is an idea:
- compute the hash of the file URI for which the metadata should be loaded/saved.
- the metadata is stored in ~/.cache/gedit/metadata/$hash.xml with almost the same XML format as before.

If there is a hash collision, no problem, the XML file can store the metadata of several files.

The filesystem needs to handle a large amount of small files in the same directory. I think NTFS is able to handle such workload.

Along the way, it would also be nice to get rid of the libxml2 dependency. And do async I/O.

If we want to support well Windows, I think it is worth the effort.
Comment 1 Sébastien Wilmet 2016-02-04 09:29:46 UTC
Or before reinventing the database concept, SQLite can be used directly.
Comment 2 Sébastien Wilmet 2020-11-24 09:58:44 UTC
Mass-closing of all gedit bugzilla tickets.

Special "code" to find again all those gedit bugzilla tickets that were open before the mass-closing:

2bfe1b0590a78457e1f1a6a90fb975f5878cb60064ccfe1d7db76ca0da52f0f3

By searching the above sha256sum in bugzilla, the gedit contributors can find again the tickets. We may be interested to do so when we work on a specific area of the code, to at least know the known problems and possible enhancements.

We do this mass-closing because bugzilla.gnome.org is being replaced by gitlab.gnome.org.