[Twisted-Python] schemas (in Zope and Foolscap)

[Brian Warner]

[my apologies if this gets duplicated, I've been having SMTP problems]

Stephen Waterbury <waterbug at pangalactic.us> writes:

> I am in the process of converting some of my code to use zope.schema
> instead of a similar thing that I independently invented.  Since I am
> also planning on using Foolscap, and since Foolscap has a schema
> module, I compared zope.schema and foolscap.schema, and to me they
> seem to have much overlap in design intent.  In particular, in the
> zope.schema use cases ...

> So I was wondering -- would it make sense to use zope.schema
> in Foolscap?

Yeah, that sounds quite intriguing. The Foolscap schemas serve a number of
similar purposes:

#1: provide a clear place to document a program's remote interfaces. This
    role is aimed at humans, not programs.

#2: make it convenient to enforce those interfaces on the receiving end.. by
    relying upon the guards, the code that actually does stuff is easier to
    read and easier to analyze for other potential problems

#3: enforce those interfaces on the sending end, to bring the discovery of
    programming errors closer to their cause

#4: enforce those interfaces at the receiving *wire*, to mitigate
    resource-exhaustion attacks

#1 is satisfied by pretty much anything, as it's more a set of documentation
#conventions than anything else. The existing zope.interface.Interface class
#does this pretty well.

The rest require that the interfaces be machine-parseable. I enhanced z.i's
Interface (in foolscap.RemoteInterface) to allow the arguments and return
values to have meaning.. if zope.schema does something similar, I'd love to
take a look at it and see if it can capture the same expressiveness.

I'm undecided as to whether #4 is a good idea or not. It seemed like a good
idea when I first started, but I've had some smart people tell me it's not
the best place to attempt to solve DoS problems. Worse yet, the
implementation is so incomplete that I've personally had to disable schema
checking on things that would otherwise be useful (in particular I think a
"PolyConstraint" in which the two branches are both containers fails to match
the tokens on the wire correctly, even though such a thing would be quite
useful just at the post-serialization phase). So I'm tempted to drop #4 as a
design criterion and if z.s can represent enough to make that work, great, if
not, drop the feature.

> A nice practical factor is that zope.schema has been packaged as
> a separate namespace module, similarly to zope.interface.

I have to admit that I'm slightly hesitant to add a new dependency. But maybe
it isn't too big or too unwieldy. There doesn't seem to be a debian package
for it, though..

But I'll definitely check it out. Thanks for the suggestion!

 -Brian