-
Notifications
You must be signed in to change notification settings - Fork 1
RFF4 — Feed Views
Request For Feature: 4
Views are a fundamental feature of Freeder. This issue defines what they are and specifies the format used to define them.
What people look after when they use a feed reader is to be able to read feeds. They could want to read the last feeds. But not the one they've already read. Except this one, which is a reminder and must appear before all the other ones, regardless their publication date. Oh, and not the entries from this feed, it is boring.
Well, user needs can be very tortuous so we need a flexible design to handle it. This flexible design is called "views". [Section 1] defines views case of use. [Section 2] establishes a somehow official specification of the format used to describe views. [Section 3] highlights some known limitations of the system we adopted.
As exemplified in the introduction, views are used to display feeds entries according to quite complex conditions. So the view system enables users to customize what they can read in Freeder. But they can also add more views in order Freeder to fit both the time they have and their mood.
It may also lead to new features such as Memos. It would simply be a special feed (probably provided by another application) taged as, saying, _sticky and a home view rule that place _sticky-tagged entries before all other ones.
Another special view is the public view. The user can enable anonymous people to read its feeds, as a traditionnal news list, but may want to hide some content. Thus, the public view rule will be such as _private-tagged entries will not be displayed in it.
But even if the user does not define any other view than the home, the view system will be implicitly used to display pages like tag pages, that display every entries marked with a given tag, or feed pages, etc.
Views follow the same naming convention as tags. Since tags have not been standardized in RFFs yet, here is a quotation of tag naming convention:
Tag names can be freely set among the set of all UTF-8 based words. However, there are some conventions that should be considered since they have an impact on how certain tags are handled.
Tags beginning with an underscore (
_) are known as "system tags". They are intensively used by Freeder core to store information about entries such as whether they have been read or not.But fundamentally, they are just tags like the other ones. Actually the backend doesn't even know that convention. It is just taken into account by the user interface that chose not to display them — or to display them in a different way — since they can be unrelevant for the user.
The second convention is more deeply implemented. Tags that begin with a dollar symbol (
$) MAY be intercepted by the backend and handled in a different way than common tags. If it is recognized to be associated with a special behaviour, the tags is called "virtual tag" and can even not exist in the database. If not, it is considered as common tag. This is NOT RECOMMENDED to name your tag with a leading dollar symbol.The most used vitual tag is
$allthat behave as if it tagged every entries.
(Yes, this is a quotation of a non existing text. So what?)
An example of virtual view is the tag views. It whould be a waste of ressources and a design issue to add an entry in the view table for each existing tag. Instead, views named like $tag_foobar show the tag page of foobar.
Note that we could not use $foobar for that purpose. It would have been ambigous for cases in which $virtualview is a non tag-based virtual view but a tag named virtualview exists. So wee needed a prefix and chosed $tag_. Hence, system tag pages will be view containing two consecutive underscores in their names. Be careful not to forget them.
There are also system views, such as _home that is the home page or _public that I think you will guess what it is.
Views are stored as a simple text rule formatted according to the following specification. We wanted this format to be at the same time:
- Concise;
- Human readable and easy-to-learn and -remember;
- Fast to parse;
- Expressive and extensible.
Concision means that it must be a single line rule, not a complicated routine that could have lead to security and performance issues.
Concision must be due to simplicity, not to compression. Hence, it would allow rules to be easily read and written by human beings in a coherent and easy-to-learn syntax. Additionnally, it would be easy to parse for a computer.
The expressiveness required involves selecting entries by their tags, their origin feed and sort them by publication date for example.
This system is basically tag based since Freeder is tag based.
A rule is a sequence of space separated entities called "words". Hence if spaces occur inside words, they must be escaped with a leading backskash (\) and so backslashes themselves must be escaped.
rule ::= word( word)*
word ::= ([^ \]|\ |\\)*
Word meaning depends on its position and its prefix.
Prefix can be either:
+--
BY(not case sensitive)
Before the first occurence of BY, the prefixes + and - respectively adds and removes entries from the selection tagged with the reminder of the word. For example, +foobar selects all entries marked with the foober tag.
If the prefix is BY (or by, or By, or even bY), the following characters of the word are omitted. This word is a separator between selection of tags and order instructions.
After the first BY prefixed word, + and - are interpreted as order by respectively increasing and decreasing order. The reminder of the word is either a tag or a virtual tag considered internally as a variable. That means that it could be more than a boolean. For example, it can be $pubDate, that will be a date.
"Increasing" order for tags means that it begins with entries that are not tagged and finishes with tagged ones.
This specification does not specify what happen when there is more than one occurrence of BY. It may be used for some extension.
For the introduction example, the rule is: +$all +_sticky -_read -boring BY -_sticky -$pubDate
It will show unread or sticky posts that are not boring and sort them (1) by stickiness (sticky before) and then by decreasing publication date.
Note that the order is important. The following rule +$all -_read +_sticky shows sticky entries even if they are marked as read.
This rule format has been designed with extensibility in mind. It is easy to imagine extensions using more prefixes or based on virtual tags, such as a priority system.
Views are intended to factorize as much as possible both user interface and backend code. But some behaviour still need to be hardcoded. For example, it would be useful to see which feeds are tagged with a given tag on its tag-specific view, although no point of this system can do it in a general way.
Furthermore some specific views are impossible, like for example displaying sticky by increasing date and then other entries by decreasing date.
View system is a both fundamental and flexible part of Freeder core. Its flexibility could lead to very powerfull extensions. For example, public views available as Refeeds (view presented as Atom feed).
Élie Michel, 07.19.2014