syncany-team team mailing list archive

[Fabrice Rossi <Fabrice.Rossi@xxxxxxxxxxx>]

Hi Philipp,

Le 05/12/2013 00:05, Philipp Heckel a écrit :
> I finally got around to look at your code, sorry for the delay.

No problem :-)

>> Philipp, does that suits you better? If this is the case, I will add
>> proper documentation and tests, and unify this with other ids.
>>
> 
> Go for it. Looks perfectly fine to me. I know that you are not happy with
> the memory consumption, but it'll have to do for now. It would be great to
> have FileContentId, MultiChunkId, etc. all based on ObjectId. I'll merge
> the current state in the master, and you can build on that.

Ok, perfect, thanks!

> Be sure to remove ByteArray afterwards.

Will do.

>> [..]
>>
> 
> In short (what we discussed):
> a. Typesafe IDs through concrete implementations
> b. Flexible size at runtime/compile time
> c. Low memory footprint (b/c we have many many IDs)
> 
> As we discussed, this is tricky, because (a)+(b) and (c) basically
> contradict. 

Sort of.

> As I understood you, a low footprint can be reached by using
> primtive types (two longs (2*64 bit) and an int (32 bit) for a SHA1 sum)
> and less abstraction. Type safety needs abstraction and a flexible size
> can't be done without arrays or lists.

Dynamic flexibility can't. But we could have a few specialized classes
just in case.

> I am not sure if it is necessary to have the size configurable at runtime.
> We could also make this an application wide constant, but that would imply
> that all checksums and all file IDs must always be based on SHA1 and hence
> be 20 bytes long. This is my major concern here.

Agreed.

> Do you think that's a bad thing?

Do you mean missing configuration? No, that definitely something that is
not needed now, in my opinion. And for the sizes, it could be local to
each concrete Id subclasses, as I did in the FileId, couldn't it?

Cheers,

Fabrice