-
Notifications
You must be signed in to change notification settings - Fork 4
Development Discussion
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
disconnectedevent, that must be properly handled by allElements (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.
| Type | Handler | Create Args | Title | Stream |
|---|---|---|---|---|
| Text | text/plain |
content |
first line of content | - |
| Image | image/* |
"Image", "Photo" + date | - | |
| Website | text/html |
URL | x | |
| Video | video/* |
meta | x | |
| Youtube | URL includes "Youtube" |
video_id? |
meta | x |
| Audio | audio/* |
meta | x | |
| Feed |
application/xml+atom, application/xml+rss, <link rel="alternate"> in HTML |
meta | - | |
| Collection | ^ | ^ | "Collection" + meta | ^ |
| Document | application/pdf |
meta | - | |
| Calendar | text/calendar |
meta | - |
- 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.
-
ObjectRediscould fire anobject_cached/object_loadedevent. This could be a good place to register event listeners (again).