Dietmar Maurer

> Including hardlinks in the image is not entirely trivial. That's because casync's serialization format puts an emphasis on being "composable", i.e that the serialization of a directory is strictly...

This basically stores hardlinked content multiple times, which makes using .catar format quite unefficient if you have many hardlinks. The deduplication layer may reduce space waste for some cases, but...

1.) we want a cache and journal to speedup read/writes 2.) we do not want to loose any data on power failures (that is whats the journal for (usually))

> Can you give a short example where it makes sense to use a `Key` as a prop value? While I agree that _if_ you need it, `Key` is better...

> @maurerdietmar Is there any reason why your component props cannot accept a concrete type of `Key` (e.g.: `&'static str`) instead of Key in the props and pass the concrete...

> For now, it's exposed and used for the consumption in vnode/vlist. Do we want to guarantee the `Hash` and `From` as a stability guarantee like this? Implementing Hash is...

> Wouldn't it be better to just drop the type Key and use IString instead? It feels like unnecessary maintenance burden. Or AttrValue, which is more flexible...

> > Or AttrValue, which is more flexible... > > It's the same object, just a type alias Ah, forgot that. Anyways, drop the type Key and use IString instead...

+1, I also need this

Just want to mention the previous suggestion: Simply use IString for key. From what I see: 1.) There is no allocation necessary for static strings, which is the most common...