Re: [Monotone-devel] mtndumb & public cert_id

[Thomas Keller]

Zbigniew Zagórski schrieb:
> Hello,
> 
> I'm slowly hacking monotone dumb transport for my personal
> use (i don't have time to polish it to publishable state)
> and found that it's very slow in creating merkle tree of
> revisions and certs. It's because there is no access to
> cert_id (it's SHA1 of all cert values joined with colon).
> 
> For dumb protocol and any other tool that could simulate
> monotone server it's a must to have possibility to query for:
> 
> - packet of specific cert
> - ids of certificates for given selector (or only revision)
> 
> Currently cert packet api provids only "get all cert packets
> of revision". It's usually redundant information because we
> usually need only cert_id and packet is needed only if
> algrorithm decides that it's to be transfered.
> 
> So my proposition is to add new public entity 'cert_id' and
> commands to retrieve it. For sake of simplicity it will be the
> same as database cert_id (hash field of revision_certs table).

I never dived much into the merkle tree thing, but if I understand you
correctly this needs the signature / sha1 of a single cert in order to
determine if it needs to be send over the wire or not, right? And you're
basically looking for something which is faster than packets_for_certs
REVID which only takes revisions, but not selectors, and which outputs
more things than you actually need, correct?

While adding new commands for this sounds reasonable at a first glance
(100% backwards compatible with any automation implementation), I wonder
if it wouldn't be better to just hack packets_for_certs (in a
backwards-compatible way) f.e. by changing its first parameter, the
revision ID, to a selector. Now you then still get all cert packets in
return, not just the IDs which you need for the merkle tree, but is this
really such a huge speed penalty?

Thomas.

-- 
GPG-Key 0x160D1092 | address@hidden | http://thomaskeller.biz
Please note that according to the EU law on data retention, information
on every electronic information exchange might be retained for a period
of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en

signature.asc
Description: OpenPGP digital signature