[Twisted-Python] Is there pb documentation somewhere?

[Kevin Mcintyre]

This discussion seems relevant to a design pattern "Yearbook Lifecycle"
that I'm using for athleets.com and junkeet.com.

Design Goal:

1) Maintain yearbooks across state, allowing students to delegate access
control to classmates as a series of transformations (recursive web
renders) - here sign my yearbook...here read what so-and-so wrote..can I
take your yearbook to PE, we might skip class.

2) Persist inside a context indexer that answers yearbook queries, with
generic access to the t0 and viewable access to t1+ transforms with request
controls for represented as e0, e1 being another recursive web template
kept within the master at t-1

So a complex use case would be a yearbook message like "OMG - did you read
{s1.p3.t4}? cause {e4.s3} said f_td(after|before) {e2.s6} was kissing
behind {p3.t0.a4}.  See you this summer good luck at
{owner.ext['college']}! BFF, {s3}"

Fake Model

YearbookPage(Element):
SignedYearbookPage(YearbookPage):

Yearbook(pb.Copyable)
-pages
-accessControlLog
StudentYearbook(pb.Viewable)
--transformation

YearbookServiceTransformer(??)

Publish(pb.Root)
    remote_issue_yearbook(studentid=None): // none can read but not signed

Athleets.com is ready(ing) for yearbook-ish events, ie when a players get
traded or hurt.  Other events act across yearbook motif regenerating the
t0 when athlete data changes which republishes all copies non t0 that exist.

The Sender Receiver Model from the example is difficult to follow cause I
tend to think of Originator only.  The originator being a service that
waits for clients in need of a working copy.  A sender, doesn't exist...it
would be more of a challenger, that if recognized as more authoritative,
replaces the rb.Root service.  Outside of the copyable I'm trying to
upstream via remotes pieces within the copyable that need updating.  I'm
delving into viewable to bring caller identity data to the web templating
process not necessary restrict access.  But also to build a system that
maintains audit history within the yearbook model. Getting to areas of
non-working code, so let me report back any success.

Cheers
Kevin



On Tue, Aug 5, 2014 at 11:55 AM, Glyph Lefkowitz <glyph at twistedmatrix.com>
wrote:

>
> On Aug 4, 2014, at 9:47 PM, Daniel Sank <sank.daniel at gmail.com> wrote:
>
> glyph,
>
> >> 2. Is there a specification for the pb dialect of banana?
> >>
> > Beyond the code, no.
>
> Ok.
>
> > I would be happy to answer questions, but obviously I'm not super
> responsive :).
> > Let me know what you need.
>
> For two personal projects, I would like to have a reasonable remote
> objects library in python. I need something which can announce state
> changes to clients, and receive state change requests from clients. My
> solution:
>
> 1. Make server side class which can spawn Cacheables when it wants to tell
> clients of its existence.
> 2. Give RemoteCaches to clients and use observe_* methods as appropriate.
> 3. Stuff a Viewable into the RemoteCaches so that clients can request
> state changes.
>
> Question #1: Is this a reasonable use of pb?
>
>
> Yes.
>
> This all worked great until I ran into a bug. In trying to fix the bug, I
> found that
>
> 1. pb code is really hard to understand
>
>
> Sorry about that.
>
> 2. exarkun's thinks pb is bad and that I should implement what I need in
> AMP.
>
>
> I really wish we would stop calling things "bad" and "good".  This isn't a
> helpful classification.  PB is adequate for a particular set of
> requirements.  Those requirements are somewhat unusual, and AMP is better
> for a lot of use-cases.
>
> It sounds to me like you are a lot more interested in
>
> 3. exarkun thinks banana and jelly are reasonable.
>
>
> Again, what does "reasonable" mean in this context?
>
> Let me explain my own opinion about this.
>
> Banana is a perfectly serviceable low-level marshaling format.  It's
> pretty efficient when compared to something like JSON, and has compression
> mechanisms which can make it even more efficient (the "dialect" support you
> referred to).  The only thing about it that isn't very general is that its
> implementation (although not the protocol specification) hard-codes the PB
> abbreviated-string dialect.
>
> Jelly is higher level, but more language-specific. Its specification
> implicitly encodes numerous Python implementation details, like the
> distinction between "tuple" and "list".  It also couples very tightly to
> your program's structure.  This can be a real benefit to getting a protocol
> up and running quickly, but it still allows you to create protocols where
> you don't really know what the wire format is, where you develop hidden
> dependencies.  In more complex protocols (where the "ease of getting up and
> running quickly" thing really starts to shine) this attribute of Jelly can
> cause real difficulty in any kind of cross-system communication:
> communicating with a peer from a different language, or even in Python
> without access to all the protocol class definitions from the original
> system, is hard because it requires reverse-engineering.  This is where it
> becomes "bad".  Still, it isn't as big of a disaster security- and
> maintenance-wise as Pickle.  The information you need *is* recorded in
> the code, it's just spread out, you don't need to work backwards from
> protocol dumps.  If I were going to spend some time maintaining PB, this is
> where I'd focus: if the schemas were a bit more explicit, could be
> collected into one place more easily, and were all validated in advance
> (before passing deserialized objects to the application code, or
> serializing them across the wire), then these problems could be addressed
> without changing the API too much.
>
> PB basically just inherits all of the benefits and caveats of Jelly.  It's
> a trivial serialization of remote references to objects.
>
> Question #2: Would you recommend implementing a simplified replacement for
> pb on top of banana/jelly, or starting over from AMP? I favor the
> banana/jelly route because the protocol seems intrinsically flexible, but I
> read your blog explaining why protocols like banana are bad, so I'm
> confused about what I "should" do.
>
>
> First of all, don't take my development advice as gospel.  When I write an
> article and publish it, I'm just trying to make people aware of issues they
> may not have considered; make your own decisions about how to write your
> own code.
>
> (Unless your decision is to write it yourself in PHP, of course, in which
> case you are a danger to yourself and others and should be remanded to
> compulsory treatment.)
>
> It seems like PB fits your style, and the problems with it are all
> tractable and fixable.  I am sad that you're not getting the development
> support you need to maintain it (most of all I'm sad you're not getting it
> from me!) but let's see if we can fix that.  I'll start by replying to your
> other email.
>
> One thing that might speed things along is if you can help out with some
> code reviews.  We've got a _really_ long queue right now and that's making
> it hard for me to spend any focused effort in one particular area.  I'm
> happy to trade 2-for-1 - if you do two code reviews, I will regard it as an
> immediate obligation for me to review a ticket you direct me to ;).
>
> It might also help to write more small, simple patches for PB.  Especially
> adding docstrings to make the nature of your other, more complex changes
> easier for reviewers to understand.  These would also be easier to land,
> and a couple of decades in open source has taught me that nothing motivates
> development activity like successful development activity ;).
>
> Good luck,
>
> -glyph
>
> _______________________________________________
> Twisted-Python mailing list
> Twisted-Python at twistedmatrix.com
> http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/twisted-python/attachments/20140806/86e2b500/attachment-0002.html>