syncany-team team mailing list archive

[Fabrice Rossi <Fabrice.Rossi@xxxxxxxxxxx>]

Hi Guys,

My two cents below.

On Thu, Dec 5, 2013 at 10:17 AM, Gregor Trefs
<gregor.trefs@xxxxxxxxx>wrote:
> I don't get myself used to the idea to use the ID to distinguish
> different class types (e.g. Multichunk, FileContent). If an instance
> of  a class has an ID, then the type information is already encoded
> in the instance. Under the assumption (and I have the impression)
> that you want to use the ID as a standalone concept (e.g. storing in
> an Index to avoid fetching all multichunk information) then you may
> use a weak reference from the id to your instance.

WeakReference sounds a good idea to reduce the memory usage in long
standing (daemon mode) for syncany. When you start Syncany, it has to
walk the full file tree. This induces load a lot of stuff that could be
weak referenced two. Then when the watcher starts, hot files will
probably see there weak referenced meta data kept in memory while the
other files will disappear.

But in my opinion, this has almost nothing to do with the id we are
talking about. Philipp explained in quite clearly. I will only add that
ids are more or less primary keys in the meta data database. They are
really needed to do clean cross referencing.

My main justification for using strongly typed ids was my personal
experience with a graph analysis research code in which I had the stupid
idea (sounded clever at that time), to have everything (graph nodes,
graph edges, clusters of nodes, etc.) int indexed. This was a
_nightmare_ to debug, with numerous type errors, like looking for a node
with a cluster index, etc. A total disaster.

> You would be able to stay typesafe without imposing an own
> inheritance structure upon ObjectID which I assume to be rather flat.
> This satisfies point a. For point b and c I thought about UTF which
> has this dynamic size concept (as far as I remember). Only use that
> amount of memory that is really needed. This is a trade-off beteen a
> flexible size and a low memory footprint.

I guess by a you mean low memory, b type safe and c runtime configurable
(or something similar, I'm not sure about the mapping). The idea of the
type hierarchy on ObjectID is to avoid reimplementing hashCode and equal
in all Ids classes, but that could be done. By UTF, are you referring to
UTF-8 and other variants? This is indeed variable size encoding, but I
don't how we could adapt that in our context.

Thanks for you input, and please elaborate on those points as this seems
a bit tricky.

Cheers,

Fabrice