Development Discussion - noyainrain/wall GitHub Wiki

Analogous to assertRaises, implement an assertion for events that can be used as context manager:

with self.assertEvent(cat, 'meow'):
    cat.meow()

Like in JavaScript, an event should be called just as the method that dispatches it. Handlers should be called like the event with an on prefix. In SJMP however, this conflicts with call response messages. Events could be integrated into the SJMP protocol, for example with an event prefix or suffix. This would also have the advantage that events could automatically be converted to JavaScript Events on the client side.

At the moment, PostElement contains an iframe which in turn contains the post content. Thereby the subclass API gets less intuitive (content must be queried via special content property; extra contentAttachedCallback()). We could move the iframe out of PostElement, for example to PostSpace.

• createdCallback(): build UI, e.g. load template, register event handlers for child elements
• attachedCallback(): activate, e.g. do network stuff, register global event handlers / intervals
• detachedCallback(): deactivate, e.g. unregister global event handlers / intervals

We could use the browser history and routing more like a traditional webapp. Screens would be possible endpoints at the moment: #, #posts/<id>, #post-note, #post-history, #post-url:url=<url>, #post-photo, #connect, #login.

When the connection is interrupted, messages delivered to the client might be lost and the client might be in an invalid state after reconnecting. Possible solutions:

• Emit a disconnected event, that must be properly handled by all Elements (e.g. Screens). Elaborate solution.
• Restart the app. Quickfix. The current user action might be canceled (e.g. loosing some just entered text).

In addition, we could delay the disconnected event (on both server and client) and buffer messages on the server for a small amount of time. If the client reconnects in this time window, just send the buffered messages. This would however be some sort of duplication, because TCP is already responsible for packet delivery...

After the active user's role changes, the client might be in an invalid state (e.g. the user sees / does not see actions that he/she is allowed / denied to). Analogously to above, the solution would be to emit an event that must be handled by Elements or to restart the app.

If we move database interaction (DRY) and authorization to Collection, it depends on more attributes of Thing (id, allow_modification_by_others). Either it stays a Mix-In and the host (Wall and CollectionThing) has to provide those or it just extends Thing. Thus Wall would become Object > Thing > Collection > Wall. Or Wall could get an attribute content that is a Thing > Collection.

• data URLs are converted to http URLs and stored as files on the server
• Stream means that content data is streamed directly to the clients. Later, the stream could be multiplexed by the server, so that every display is guaranteed to receive the same content (hard to do / not possible for Website, Youtube).
• non-stream things "cache" their content (data) and refresh it in regular intervals

• When an object is destroyed and removed from the cache, all registered event listeners die too.
• ObjectRedis could fire an object_cached / object_loaded event. This could be a good place to register event listeners (again).