Hi Martin, I am not so confident with the code base that I can judge which methods goes into which classes. So I am just going to tell you about cohesion. In OO programming one should strive to achieve as high a degree of cohesion for each class as possible. That is each class should serve ONE specialized and well defined purpose. Hence I think it would be great to split the Runtime class into multiple pieces.
Mixins are the think you would want to use in the case of your comparisons, since it is not something which is only well defined for one protocol, but a given comparison make sense for multiple protocols. -- Janus Den 31/01/2008 kl. 4.40 skrev Martin Geisler: > Hello, > > I have thought a little about how we can split the current Runtime > class into smaller pieces. Currently runtime.py contains five classes > and the Runtime class contains 26 methods. That is too much > information in one file. I think we can group the methods like this: > > Basic infrastructure: These methods are not specialized to deal with > crypto as such, they simply provide a means for players to talk with > each other: > > * __init__ > * add_player > * shutdown > * wait_for > * synchronize > * callback > * _exchange_shares > > Protocols for passive security. This includes Shamir sharing, PRSS, > and opening of such shares: > > * shamir_share > * _shamir_share > * _recombine > * prss_share > * prss_share_random > * open > > We also have the basic protocols for doing arithmetic with shares: > > * add > * sub > * mul > * xor_int > * xor_bit > > Then comes the comparison protocol from Tomas' progress report, also > knows as the SCET comparison protocol: > > * greater_than > * _finish_greater_than > * _diamond > * convert_bit_share > > The final group would be the newer comparison protocol, also by Tomas: > > * greater_thanII > * greater_thanII_preproc > * greater_thanII_online > * _finish_greater_thanII > * convert_bit_share_II > > > I propose that we split the Runtime class into these classes: > > * BaseRuntime containing common code needed by all runtimes. > > * PassiveRuntime inheriting from BaseRuntime with the standard > Shamir-based protocols. > > The comparison protocols could live in their own classes, maybe named > > * ComparisonToft05Runtime > * ComparisonToft07Runtime > > for a lack of better names. These classes would not inherit from > PassiveRuntime since they can also be used with a runtime that > provides protocols for active security. > > So they could be made as mix-in classes instead. That is a class that > you inherit from if you needs its functionality, please see > http://en.wikipedia.org/wiki/Mixin for some background. > > A combined runtime class could then be made as > > class Combined(PassiveRuntime, ComparisonToft05Runtime): pass > > or > > class Combined(PassiveRuntime, ComparisonToft07Runtime): pass > > depending on your need. The comparison protocol would be present in a > greater_than method in both cases. When we have an ActiveRuntime > class, then programs may define their runtime class as > > class Combined(ActiveRuntime, ComparisonToft07Runtime): pass > > > I guess none of us is used to mixin classes, but the advantage as I > see it is that we avoid the problem of "blessing" one particular > protocol as the "right" one. We could of course also make the > inheritance hierarchy so that there is a ComparisonRuntime class that > inherits from PassiveRuntime and implements a particular comparison > protocol. But then how would we easily reuse that code for the active > case? A simple dot graph showing that I mean in the case where we use > normal inheritance: > > <inheritance.png> > And another graph showing the mixins: > > <mixin.png> > Here the lower four classes would esentially be empty containing only > a pass statement like the examples above. > > -- > Martin Geisler > _______________________________________________ > viff-devel mailing list (http://viff.dk/) > viff-devel@viff.dk > http://lists.viff.dk/listinfo.cgi/viff-devel-viff.dk _______________________________________________ viff-devel mailing list (http://viff.dk/) viff-devel@viff.dk http://lists.viff.dk/listinfo.cgi/viff-devel-viff.dk
