'''
a website wants to show you different arrangements of framed pictures
on a wall. you can click, drag, scale, and rotate pictures in place.
you can also drag new pictures in to it.
spacing is uniform and settable-- if you rotate one, the readout of
the total square area changes along with the new value. you can also
select themes from the host that determine formulae for spacing, based
on established aesthetics constraints.
user clicks a picture and clicks rotate. clientside doesn't want to
transmit the whole array back to the server for calculation, but
calculation takes a long time, due to the complexity of the spacing
formulae. therefore, maintain paralell data on both sides: client for
displaying and interfacing, so as not to inform the server of every
mouse click, and server side to decrease transmission redundancy and
size. do not broadcast every click, but do not broadcast entire
interface state. constraint-based best-fit labor distribution is
between.
changes are sent to the server in the form of the change parameters
(perhaps a change object), the layout is updated roughly (still by
server-side procedures), and then precisely (along with the sq. ft.
readout) when the calculation completes. the interface remains
continuously active.
Partial cast:
'''
class PictureClientSide:
def __init__( self, image ):
self._image= image
def on_scale( self, *params ):
change= self.whatchange( scale, *params )
self.tell_the_server( change )
def on_rotate( self, *params ):
change= self.whatchange( rotate, *params )
self.tell_the_server( change )
def server_says( self, layoutchange ):
renderchange( layoutchange )
class PictureServerSide:
def __init__( self, image ):
self._image= image
def client_says( self, change ):
preliminary= self.calculation()
preliminary_change= whatchange( preliminary )
tell_the_client( preliminary_change )
completed= self.other_calculation()
completed_change= whatchange( completed )
tell_the_client( completed_change )
'''
It's too tangled to proceed. What if a second client 'change' and the
first server 'completed' cross paths? Will you cancel the first
change explicitly or just drop it? Are you shooting for five-nines
quality, or one? What about signal loss and reordering? Will you
retransmit an entire message upon suspected loss, or intervalled AYT
messages (are you there)? What about an immediate time estimate? How
general can the underlying framework be? The rest is a brainstorm.
Please critique.
'''
class PictureClientSide( ClientSide ):
settings= Setting1(), Setting2()
@incremental
def server_says( self, layoutchange ):
renderchange( layoutchange )
class PictureServerSide( ServerSide ):
settings= Setting3(), Setting4()
'''
We may want to distinguish requests in both directions. Depending on
which side takes care of the rotation, server_says may divide based on
increment.
'''
class PictureClientSide( ClientSide ):
@incremental( 1 )
def server_says( self, layoutchange ):
renderchange( layoutchange )
@incremental( 2 )
def server_says( self, layoutchange ):
renderchange( layoutchange )
'''
Furthermore, you may want the time estimate in its own method.
'''
class PictureClientSide( ClientSide ):
@incremental( layoutchange, 1 )
def server_says( self, layoutchange ):
renderchange( layoutchange )
@incremental( layoutchange, 2 )
def server_says( self, layoutchange ):
renderchange( layoutchange )
@message( timeout_message )
def timeout_message( self, etc ):
report( etc )
--
http://mail.python.org/mailman/listinfo/python-list
