Architecture and Design Considerations

Updated 3,233 Days AgoPublic

Actions

Roundcube Next is going to entertain a variety of applications ("apps"), integrated with one another to provide the best possible human experience for messaging and scheduling, among other things.

This builds an application suite that will need to be able to deal with intricate communication, data storage and presentation layers, existing (JavaScript) library's capabilities, potentially including issues or restrictions with multiple tabs and multiple windows.

The division of components that make up the complete Roundcube Next application suite has already been established, in that we will at first entertain email messaging, calendar-based scheduling and address books (milestone $x-$y), bearing in mind other object types and different contexts are on the roadmap as well (instant messaging, and others).

These components are seated in a Roundcube Shell, which for the purpose of a sustainable roadmap needs its horizon defined.

Application Model Design Considerations

Data Communication, Data Storage, Communication and Presentation Layers

For a given user, more than one account may be configured. Multiple "virtual folders" may aggregate the different types of messages from each account in to a merged view, meaning that the INBOX is an aggregate of all INBOX folders, Drafts and aggregate of all Drafts, and such and so forth.

This means that when a passive event is triggered (Data Communication, passive if something happens on the server and the client is told / notices), the representation in the internal structure (Data Storage) needs to be able to represent two things:

1. The event happened for account A, updating the current local working copy of account A's (meta-)data.
2. The internal virtual aggregate of the data associated with account A and the data (of the same type) from all other accounts will need to be updated.

This leads to new events to need to be triggered in the client software (Communication), which depending on the current view the user is looking at may or may not cause the presentation layer to need to be updated, and in a particular way as well.

Implications on Application Model Design

For example, we know that when a new email message comes in, we want to emit an event (publish) for other applications (subscribers) to consume.

To illustrate the complexity involved, consider what a notification mechanism may need to be able to deal with at its precipice of evolution;

• If the user is already in a mail view;
  • and the real estate that needs updating to represent the new message(s) is within view;
    • an additional notification is superfluous;
      • unless the update of the presentation layer is insufficiently stimulating (compared to the importance of the event).
    • an additional notification may not hurt a user unless the notification blocks real estate in use or blocks work-flow.
  • and the real estate that needs updating to represent the new message(s) is outside the current view;
    • TODO
• If the user is not already in a mail view;
  • Notifications of different sorts may be suitable for certain data types.
  • TODO

So, when a new message comes in but the user is in a "mail" view already, however that mail view may end up being composed, it means little to both amend the list of messages in a folder display on the current real estate being viewed, and pop up a notification-like UI element to let the user know a new message arrived.

Additionally, the existing focus point (selected message UI element) should probably remain the focal point in all of this, to prevent the focal point moving on the X- or Y-axis.

Data Types and Treatment

In contrast, however, should the current list of messages displayed have scrolled beyond the slice in which the new message would have been inserted in to the current view, a notification UI element may be justified.

In another example, when a new message comes in to a "mail" app, other "apps" may want to interfere with the representation of that event;

• An iTip invitation may need to be handed of to a "scheduling" app, which may or may not consider itself a terminal end-point for the particular event.
• The same iTip invitation may need to be passed on to a notification mechanism but only after the "scheduling" app has treated the event (but considered itself not a terminal end-point).

The emission of "an event" that "is about to happen" and/or "happened" therefore deserves queuing priority capabilities as well as ordering event subscribers, each of them allowed to determine its own finality in treating the event.

There are two events here: "mail.invitationOpened" and "scheduling.invitationTreated". To establish causality, a subscriber that consumes an event must take the UID property within the event object and pass it on to the events it fires itself.

A third app (after "mail" and "scheduling") may wish to handle the first event if there is no scheduling app, and the second instead if it is present. Thus, it can subscribe in a certain priority order: ["scheduling.invitationTreated", "mail.invitationOpened"]. This order can be published before runtime, by letting the app's initializers "register" it's event consumption priorities in some data structure. The global eventing system can then prune nonexistent event dependencies and take care of firing in the right order.