Merge pull request #869 from matthiasbeyer/readme-updates
Readme updates
This commit is contained in:
commit
55ea7f8228
2 changed files with 16 additions and 38 deletions
17
README.md
17
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
|
||||
build several applications at once).
|
||||
Make sure to _not_ include some `-j 8` arguments, as cargo parallelizes the
|
||||
build process on its own. If you parallelize it with make, you end up with a
|
||||
really high load on your system.
|
||||
We use `make` to automate the build process.
|
||||
Make sure to _not_ include some `-j 8` arguments, this will _not_ work as you
|
||||
might think!
|
||||
|
||||
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
|
||||
on my blog, where
|
||||
There is a blog series which gets an update once a month 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!
|
||||
|
||||
|
|
|
@ -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.
|
||||
Only exception would be the `Entry` class, which would be a `FileLockEntry`
|
||||
underneath.
|
||||
|
||||
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`.
|
||||
`libimagentrytag` and the other `libimagentry*` libraries will be pulled into
|
||||
this library to support more advanced operations with the `FileLockEntryHandle`
|
||||
type.
|
||||
|
||||
|
|
Loading…
Reference in a new issue