Merge pull request #869 from matthiasbeyer/readme-updates

Readme updates

README.md

@@ -44,11 +44,9 @@ give you a commandline application.
 
 ### Building
 
-We use `make` to automate the build process (as `cargo` is not (yet?) able to
+We use `make` to automate the build process.
-build several applications at once).
+Make sure to _not_ include some `-j 8` arguments, this will _not_ work as you
-Make sure to _not_ include some `-j 8` arguments, as cargo parallelizes the
+might think!
-build process on its own. If you parallelize it with make, you end up with a
-really high load on your system.
 
 There are several targets for each of the sub-crates in the Makefile:
 
@@ -66,7 +64,7 @@ There are several targets for each of the sub-crates in the Makefile:
 | update   | *     | Run `cargo update`                       | `make update`   |
 
 The `Multi` targets are callable for each sub-crate. For example you can call
-`make imag-bookmark-check` to run `cargo check` on the `imag-bookmark` subcrate.
+`make imag-store-check` to run `cargo check` on the `imag-store` crate.
 
 ### Running
 
@@ -86,8 +84,7 @@ There is no RSS feed, though.
 We also have a [mailinglist](http://imag-pim.org/mailinglist/) where I post
 updates and where discussion and questions are encouraged.
 
-There is a blog series which gets a update every other week
+There is a blog series which gets an update once a month on my blog, where
-on my blog, where
 [entries are tagged "imag"](http://beyermatthias.de/tags/imag.html).
 I also post non-regular posts about imag things there.
 
@@ -105,7 +102,9 @@ which can be compiled to PDF or a website.
 These docs are not published anywhere and are not even integrated into our CI,
 so it might be broken (though it's unlikely).
 Developer documentation is also available
-[online on github.io](https://matthiasbeyer.github.io/imag/imag_documentation/index.html).
+[online on github.io](https://matthiasbeyer.github.io/imag/imag_documentation/index.html)
+and [on docs.rs](https://docs.rs/releases/search?query=imag), though they might
+be a bit outdated.
 
 ## Please contribute!
 

libimagruby/README.md

@@ -56,8 +56,6 @@ But I hope we get it in travis soonish.
 This crate will contain both the Rust bindings for imag using `ruru` and a bunch
 of wrapper code for the actual `imag` gem.
 
-We are not there yet, though.
-
 ### Why another layer of indirection?
 
 As "ruru" does not yet support modules (which is sad btw) we would end up with
@@ -67,40 +65,21 @@ E.G.: `imag_runtime_setup()` instead of `Imag::Runtime::setup()`
 
 I want to add a Ruby gem to wrap these things.
 
-So basically a piece of Ruby which uses `imag.rb` (the Rust gem) to build
+So basically a piece of Ruby which uses the Rust code to build
 `imag` as a gem which then exports a fine module system.
 
-### Ideas for module system:
+### The module system:
 
 ```text
 Imag (Module)
-  Runtime (Class)
-  Store (Class)
-  Entry (Class)
-  EntryHeader (Class)
   EntryContent (Class (inherits from String))
+  EntryHeader (Class)
+  FileLockEntryHandle (Class)
+  StoreHandle (Class)
   StoreId (Class)
 ```
 
-I would name the types the same as in the Rust codebase, to avoid confusion.
+`libimagentrytag` and the other `libimagentry*` libraries will be pulled into
-Only exception would be the `Entry` class, which would be a `FileLockEntry`
+this library to support more advanced operations with the `FileLockEntryHandle`
-underneath.
+type.
-
-If we adapt `libimagentrytag` and the other `libimagentry*`
-libraries, we would extend this type.
-
-## More plans
-
-I want to pull these libraries into the Ruby bindings:
-
-* libimagentryedit
-* libimagentryfilter
-* libimagentrylink
-* libimagentrylist
-* libimagentrymarkdown
-* libimagentrytag
-* libimagentryview
-
-Which all provide functions on top of `libimagstore::store::{FileLock,}Entry`,
-so we will implement them on `Imag::Entry`.