[server] Make "sources_by_uri" and "sources_by_eid" properties of repository I.e. do not populate these dict as repo initialization (bootstrap step) but always use information from database. This is needed because when multiple instances of the same application run, if one instance adds a CWSource the other ones will not see it. In particular, when using a scheduler instance, new CWSource will be added by the web instance and not seen by the scheduler which is supposed to update them. We thus define properties for sources_by_eid and sources_by_uri instead attributes on repository instance. CWSource entities are thus retrieved from database every time these properties are accessed. We factor out initialization of the "source" instance (subclass of cubicweb.server.source.AbstractSource) in a _sources() method. Note that this method takes care of calling "init" method on the source as well as "set_schema" (previously done in repo.set_schema(), which now only touches system_source). Accordingly the "init_sources_from_database" method is dropped along with "add_source"/"remove_source" methods. In syncsources hook, we thus drop: * SourceAddedOp operation which called repo.add_source() so that the SourceAddedHook only cares about checking source configuration now; * SourceRemovedOp and SourceRenamedOp operations for the same reason; * SourceConfigUpdatedOp as updating the live config of source is meaningless once we rely on them being retrieved from the database; * SourceHostConfigUpdatedHook hook which is now useless without call to SourceConfigUpdatedOp; In 3.10 migration script, remove usage of sources_by_uri repo attribute which, unless I'm missing something, appears useless (at least now). In tests: * unittest_datafeed: remove test_update_url method since we dropped respective hook; * unittest_ldapsource: LDAPFeedUserDeletionTC.test_a_filter_inactivate() currently fails because it still relies on live config being updated, this will be fixed in the next changeset once all "live source" logic will be removed.

.. -*- coding: utf-8 -*-

RSS Channel
-----------

Assuming you have several blog entries, click on the title of the
search box in the left column. A larger search box should appear. Enter::

   Any X ORDERBY D WHERE X is BlogEntry, X creation_date D

and you get a list of blog entries.

Click on your login at the top right corner. Chose "user preferences",
then "boxes", then "possible views box" and check "visible = yes"
before validating your changes.

Enter the same query in the search box and you will see the same list,
plus a box titled "possible views" in the left column. Click on
"entityview", then "RSS". 

You just applied the "RSS" view to the RQL selection you requested.

That's it, you have a RSS channel for your blog.

Try again with::

    Any X ORDERBY D WHERE X is BlogEntry, X creation_date D, 
    X entry_of B, B title "MyLife"

Another RSS channel, but a bit more focused.

A last one for the road::

    Any C ORDERBY D WHERE C is Comment, C creation_date D LIMIT 15
    
displayed with the RSS view, that's a channel for the last fifteen
comments posted.

[WRITE ME]

* show that the RSS view can be used to display an ordered selection
  of blog entries, thus providing a RSS channel

* show that a different selection (by category) means a different channel