M3 mail & RSS-reader





  • When implementing this please do not mix these 3 vastly different functionalities.

    The mail client can be a separate process without any understanding of website technology foo. While I fear its functionality will mostly be implemented with some fancy javascript, an (optional) HTML viewer should live in a separate constrained chrome renderer process. A good implementation should allow a standalone operation or UI-integration into Vivaldis sidebar.

    RSS subscriptions are a special form of bookmarks, how to integrate with existing code/UI is more taste than technical decision. All a subscrition display needs is a way to query some feed metadata (already done for regular bookmarks).

    Displaying RSS feeds requires "just" a special form of a chrome renderer to process special XML tags, keep track of entry tags (read/important/etc.) as part of parsing a feed and additional loading logic to append additional data for paged feeds. Keeping data other than a registry of entry tags should be an option (as well as purging tags for older entries) to save space and improve privacy.



  • @becm
    I'm not quite sure I understand why people call RSS a form of bookmark instead of a message? Bookmarks are a static link that you click to pass a URL to the browser to open a page. An RSS feed has a sender, date, topic, and body (often a sample or preview of the page), like an e-mail message. The workflow that I, and others use, is to review the RSS feeds in the reader, which means 'opening the body' and rendering it like an e-mail. This allows us to decide which pages to open and which to skip. Old RSS notifications may be stored and reviewed at a later point, much like an e-mail message. For my workflow, a 3-pane display like the old M2 is ideal, whereas using a bookmark like interface would be useless.



  • @nemoanonymous M2 was almost perfect, it lacked ability to middle-click on second pane to open articles in new tabs (full pages, not whatever was embedded in feed)



  • @zakius
    True about middle-clicking the second pane, but most posts (third pane) have a link in them that you can middle-click to open the page, particularly if you have that assigned as opening in background tab. In fact, that functionality is what is missing from every other RSS feed and why, for certain high volume RSS feeds, I still use Opera 12.



  • @nemoanonymous the feed (RSS/Atom) data is a linear XML document which has to be downloaded and parsed in its entirety.
    The "reading software could … present a neat display to the end users".

    • feed selection → Bookmark (URL to check regularly)
    • feed content → metadata and items (for each feed)

    The bookmark entries COULD be enhanced by the parser(/renderer) component with data retrieved from their corresponding feed or some other data related to feed-specific persisten storage (unread item count).



  • @nemoanonymous having to left click, move cursor to third pane, middle click, move back and so on isn't the most efficient way of using the reader imo



  • @becm

    Still not sure I understand the point... An individual e-mail is a linear mime encapsulated document that has to be downloaded and parsed in its entirety, similar conceptually to an RSS feed. But more fundamentally e-mails are metadata and content just like RSS feeds whereas bookmarks lack content. Why break content and metadata apart when you already have a conceptual framework for handling both together? Particularly when there is an interest in at least a portion of the customer base to implement something similar to M2's functionality for RSS anyway? I don't understand what the gain is to move to bookmarks.

    @zakius
    True enough it would be faster. I'd never really considered it that way, so it sounds like a good improvement to me, as long as the ability to open in a background tab is maintained. I typically go through my entire feed first before reading individual tabs, so opening them into the background saves a lot of time.



  • @nemoanonymous the distinction is feed-subscriptions and mail-accounts.
    Interaction with the remote point (appart from reading) is vastly different.

    RSS/Atom data is a XML file (generally) retreived via HTTP(S), containing some header info and (generally) only the latest (5, 10, whatever) "news" items in bulk. A feed subscription is just an URL to this file ("bookmark").

    Mail servers provide various operations via user-authenticated sessions. Single message retreival is supported. Transfer protocols and (regular) content do not require an HTTP engine or XML/HTML parser.

    There is no mention of deviating from the way M2 actually interacts with or displays feeds (from a user perspective) anywhere in this thread (to this point).
    The (other) discussion is to give feeds their own side pannel (as I and others would prefer) or mis reuse the mail panel (again).



  • @nemoanonymous surely I meant "default browser behavior on middle click" so if you set m-click opens in bg then it opens in bg, but some people change that to fg so they are free to do so

    @becm you are talking about so called "live bookmarks"
    proper RSS reader caches contents and remembers stuff that got removed from feed itself due to size limitations (you can't expect feed to store all entries since the very beginning, can you?)

    But yeah, I wouldn't use the mail "panel"/fullpage for that, just the almost exact clone of it to separate concerns



  • @zakius the extent of feed related persistent data (history size, item flags) was not mentioned so far. I just suggested features to minimize or (partially) remove old/excessive metadata and content.
    All functionality is contained within a feed processor/renderer instance and (removal and unread count aside) largely independent from an entry in a subscription overview on the side panel.

    There is a more than ten year old RFC to refer to endpoints with older/special items (full history included). Server and client implementations are expected to support this by now.



  • @becm
    I can't speak to the back end pieces and will defer to you on that. But there is one other aspect of end-user experience that is what caused me to question this. In other RSS implementation that leverage bookmarks in what I assume is a similar manner, they inevitably create another folder in the bookmarks hierarchy where they store all of these feeds. I find this highly annoying for the same reason you dislike merging mail and RSS: it doesn't belong and shoehorns functionality into a function that makes no sense for 90%+ of end users as most end users use bookmarks as static links. This additional folder becomes something they have to remember to ignore or they can break their RSS functionality (or whatever else is using it).

    If the Devs decide to leverage bookmarks in the recommended fashion, I sincerely hope they hide it from the end users and leave it out of the bookmark UI.



  • @nemoanonymous as already mentioned: I'd prefere an additional side panel for feed subscriptions.
    So the only difference to the "3-pane" display in Opera12/M2 for feeds would be no mail (folders/accounts) related distractions in the subscription list segment.



  • Vivaldi M3 - mail client, when?
    And three years later this thread is labeled "In Progress". Disappointing.



  • @ghpy said in M3 mail & RSS-reader:

    Vivaldi M3 - mail client, when?
    And three years later this thread is labeled "In Progress". Disappointing.

    When it is solid, better to launch good and stable than something that could cause loss of user data.



  • Things I'm interested in knowing:

    • What IMAP extensions are supported? IDLE, QRESYNC, QUOTA, UIDPlus (with UID expunge), Special-Use (and XLIST), ID, CONDSTORE, SORT, THREAD, LITERAL+ etc.

    • Are IMAP keywords supported and made use of in some way in the UI for labels or tags?

    • Is oAuth2 supported as a login method for IMAP and SMTP?

    • How many connections to the IMAP server are used? 1, 2 or 4 for example. Is it configurable?

    • Is vCard supported for importing/exporting contacts?

    • What storage format is used for the actual message sources? MBOX or database? If MBOX, 1 mbox per folder or per message?

    Stuff like that.



  • @burnout426 I am sure all will be revealed when an Alpha Release is made.
    As of know we know the Vivaldi team is working on M3 (perhaps even testing a pre-Alpha version) so all we can do is to be patient and let them do their work.



  • I started to use Vivaldi in the hope that it would fulfill the promise to substitute Opera 12 as a wholesome web suite, including a mail and IRC client.

    It is still only a browser. And I can still not get rid of Opera 12 completely.

    The only other websuite I know is SeaMonkey. But I dislike its style.


  • Moderator

    @ligh M3. with RSS reader, is still in the works. It will happen.



  • @ghpy

    Actually, there are some messages on the Forum, on this subject going back FOUR years. I'm just about convinced that there will NOT be a mail client in Vivaldi.

    I'm disappointed as well. 😞


 

Looks like your connection to Vivaldi Forum was lost, please wait while we try to reconnect.