[librsvg.wiki] Start the 2020/May roadmap

[Federico Mena Quintero <federico src gnome org>]

commit 3af9c5c9780c7cd097b8960808987058825faa1f
Author: Federico Mena Quintero <federico gnome org>
Date:   Fri May 7 14:10:02 2021 -0500

    Start the 2020/May roadmap

 Development-wiki-for-librsvg.md |  4 ++--
 roadmap-2021-05.md              | 45 +++++++++++++++++++++++++++++++++++++++++
 2 files changed, 47 insertions(+), 2 deletions(-)
---
diff --git a/Development-wiki-for-librsvg.md b/Development-wiki-for-librsvg.md
index 296e26e..2a201b4 100644
--- a/Development-wiki-for-librsvg.md
+++ b/Development-wiki-for-librsvg.md
@@ -1,3 +1,3 @@
-* [Roadmap, 2020/May](roadmap-2020-05)
+* [Roadmap, 2021/May](roadmap-2021-05)
 
-* [Internals documentation](https://gnome.pages.gitlab.gnome.org/librsvg/doc/librsvg/index.html)
\ No newline at end of file
+* [Internals documentation](https://gnome.pages.gitlab.gnome.org/librsvg/doc/librsvg/index.html)
diff --git a/roadmap-2021-05.md b/roadmap-2021-05.md
new file mode 100644
index 0000000..c68eb6a
--- /dev/null
+++ b/roadmap-2021-05.md
@@ -0,0 +1,45 @@
+# Roadmap, May 2021
+
+## Short term goals
+
+### Use cargo-c to build the .so library
+
+**Why?** This will remove the need for a C compiler and the libtool
+machinery for `librsvg.so`, which is the artifact that provides the C
+API.  In theory this will make compilation more robust for non-Linux
+systems; libtool is not exactly seamless on Windows or MacOS.
+
+Also, this goes along with the "rustify all the things" line of
+development.  When librsvg had mixed C and Rust code, the final
+`librsvg.so` was linked from C object files and a
+`librsvg_internals.a` built from Rust; this is no longer the case as
+the whole library is in Rust.  However, the whole library gets
+compiled as a `librsvg_c_api.la`, and later linked with libtool into
+the final `librsvg.so`.  This is unnecessary, and `cargo-c` provides
+the machinery to eliminate this step.
+
+Issues: [#552](https://gitlab.gnome.org/GNOME/librsvg/-/issues/552)
+
+### Publish Rust crate in crates.io
+
+**Why?** Currently there is the [`rsvg`
+binding](https://crates.io/crates/rsvg) for the GObject API, but it is
+not very widely used.  Also, librsvg's Rust API is much more idiomatic
+and there's no reason to keep wrapping the C API library.  Being
+available on crates.io should make it easier to get Rust contributors,
+hopefully.
+
+The only thing that makes me unhappy right now in the Rust API is [the
+public error
+types](https://gitlab.gnome.org/GNOME/librsvg/-/issues/657).  For
+example, `LoadingError::XmlParseError(String)` is just a
+human-readable version of `xmlError` from libxml2.  If librsvg changes
+its XML parser to a Rust one, we should be able to provide more
+detailed errors via `Box<dyn Error>` opaque variants.
+
+Issues: [#635](https://gitlab.gnome.org/GNOME/librsvg/-/issues/635),
+[#657](https://gitlab.gnome.org/GNOME/librsvg/-/issues/657)
+
+## Medium term goals
+
+### Make it possible to move away from Cairo