This is a consequence of not using Javascript and the entire page refreshes.
To support flexible templates and layouts, once signed in, every template needs the variables:
The data available on templates dictates the layout and flow, but at the same time it is pointless to keep refetching the IMAP data on every single request. Folders and messages list are unlikely to have changed between requests so they should be cached.
I agree we need a cache for the mailbox list. Caching the message list is more involved, let's keep it for https://todo.sr.ht/~sircmpwn/koushin/29.
Re base variables:
The currently signed in user can easily be added and is useful for the header. The mailbox list (with unread/total messages count, flags, etc) could probably be useful for a sidebar.
I'm not sure we need these on every page:
current folder - name, and number of unread messages in it
It's not clear what the current mailbox is when you're not displaying the folder or a message in it.
current folder messages list with pagination context
This is a lot of data and I'm not sure how it would be useful.
I think we'll want to add an additional
Basedata field guaranteed to be specified for all templates. Something among the lines of:struct BaseData { Username string Mailboxes []*imap.MailboxInfo Extra map[string]interface{} }
Extracan be used by plugins to add more base fields. We can add more fields as necessary.
(In any case, what I wrote above about which fields should be included isn't final: it's very easy to add more base fields if we need them.)
Introduced a
Globalfield available in all templates in 3748b4413e69 (renamed fromBasetoGlobal, this new name makes more sense).
current folder - name, and number of unread messages in itSure, if the context of the current mailbox is not available, then none would be selected. This is primarily for the case where you display the message body on the same page with the mailboxes listing, instead of separate page. We can obviously deduct the current mailbox from the message data?
current folder messages list with pagination contextThis is necessary if you have a split view layout [messages_list + message_body], for example such as thunderbird. It is easy with Javascript, but otherwise it requires a lot of data. I think I wrote that bad above, this is needed only on the messages list and on the message display page. It is not needed in e.g. settings screen. We could also just say, single layout possibility and cut it short, but I would love to have it universal. Wdyt?
Sure, if the context of the current mailbox is not available, then none would be selected. This is primarily for the case where you display the message body on the same page with the mailboxes listing, instead of separate page. We can obviously deduct the current mailbox from the message data?
The current mailbox variable is available on the mailbox and message views already, so it should be fine.
This is necessary if you have a split view layout [messageslist + messagebody], for example such as thunderbird. It is easy with Javascript, but otherwise it requires a lot of data. I think I wrote that bad above, this is needed only on the messages list and on the message display page. It is not needed in e.g. settings screen. We could also just say, single layout possibility and cut it short, but I would love to have it universal. Wdyt?
Ah, indeed, I haven't thought about that. I'm not yet sure what the best way to do it would be. It would be easy for a plugin to add the message list data to the message view, and change the template to display it. But message list caching is important for this case, I'll keep this in mind.
More I think about this, more I am convinced we ought to keep it simple and not support the split screen layout. It is wasteful to server resources and it also is not a better layout. While it would be good that koushin is a "framework" for webmail, some opinion is not bad. Now, if Javascript is enabled, we could do this by simply using javascript remote fetch go get the message the user clicked. This means we do not need to get away from the messages list and by it we don't need to do mumbo jumbo magic with cache. The template should just have a hidden div, which 1) when displayed splits the screen (the message panel), 2) renders message into it.
I can do the JS for this - but it is not a high priority at the moment.
The simpler the things are the better. This would require only a handler which serves the message as JSON.
We can always have a plugin for the split view.
From a high level - how would you do that from a plugin?
The plugin could add a hook to the "view message" route, adding the message list to the template data. Then the template could render the additional data. The plugin could handle caching in memory.
got it, though it should in that case use same templates obviously.
Since this is marked as mvp, ~migadu, can you summarize what portion or portions of this work is considered blocking and still needs to be done?
This one boils down to having more data for the mailbox list. Will close and open another one.