Network server- / client-side messaging

[castironpi at gmail.com]

On Mar 2, 3:43 pm, castiro... at gmail.com wrote:
> '''
> Last time, we left off at:
> '''
>
> class InterfaceClientSide( ClientSide ):
>         message= MessageDec()
>         incremental= message.incremental()
>         settings= AYT( .5, 3 )
>         user_act= message.out()
>         def __init__( self, image ):
>                 self._image= image
>                 ClientSide.__init__( self )
>         def on_scale( self, *args ):
>                 change= self._whatchange(
>                         self.on_scale, *args )
>                 self.user_act( change )
>         def on_rotate( self, *args ):
>                 change= self._whatchange(
>                         self.on_rotate, *args )
>                 self.user_act( change )
>         @incremental( 1 )
>         def layout_return( self, layoutchange ):
>                 renderchange( layoutchange )
>         @incremental( 2 )
>         def layout_return( self, layoutchange ):
>                 renderchange( layoutchange )
>         @message
>         def time_estimate( self, etc ):
>                 report( etc )
>
> class InterfaceServerSide( ServerSide ):
>         message= MessageDec()
>         incremental= message.incremental()
>         settings= AYT( .5, 3 )
>         time_estimate= message.out()
>         layout_return= incremental()
>         def __init__( self, image ):
>                 self._image= image
>                 ServerSide.__init__( self )
>         @message.intervene()
>         def user_act( self, change ):
>                 etc= self.calculateeta( change )
>                 self.time_estimate( etc )
>                 preliminary= self.calculation()
>                 preliminary_change= whatchange( preliminary )
>                 self.layout_return( preliminary_change )
>                 completed= self.other_calculation()
>                 completed_change= whatchange( completed )
>                 self.layout_return( completed_change )
>                 self.layout_return.finish()
>
> '''
> Another use ClientSide and ServerSide should support is a peer-to-peer
> chat-and-game server.  And that said, it's not clear that there's any
> distinction between ServerSide and ClientSide anyway, depending on
> exactly how the listen and connect methods abstract.  How much of the
> implementation do they share?  Most.
>
> You could mark 'time_estimate' as incremental( 3 ); they're separated
> for illustration purposes.
>
> One remaining question is how to intervene in user_act, if a second
> change arrives before the previous complete.  You could combine the
> earlier change parameter in the new call and throw an exception in the
> thread handling the earlier one at its first loss of control--- and
> maybe even at once with settrace!  That tends to be costly.  Not to
> mention, change has already entered derived-class space.  ServerSide
> should make sure it's easy enough to address the issue on one's own,
> and @message.nonintervene() is available too.
> '''

The issues over here this week were delta vs. state-- if there is a
unifiable way to specify constraints on which is cheaper given what,
and transmit it, -- and, partial inheritance of not just methods,
data: overriding 'message' and wanting -its- derivatives-- user_act,
time_estimate-- to know it, without redefining.

Obvious solutions can be redundant.  self.message.layout_return is;
get 'layout_return' into the class definition.  It's immediately easy
to receive the 'ServerSide' instance as a parameter-- less so to get
both it and the 'message' instance.  If we can, MessageDec can include
data, but is still constrained by overriding 'message'.  Conclusion?
Might as well include some data in MessageDec.  How well does message=
MessageDec( ServerSide.send ) settle?