amplee 0.7 discussion page

This page is intended are referencing ideas, griefs or features around amplee 0.7

amplee 0.6 was by far the most stable and usable of amplee's releases. However it still trails a few wrong design ideas of earlier versions and those start being a real issue of amplee.

Refactoring

  • the amplee.atompub.member module needs a complete re-work. It's complicated and slow.
  • the amplee.atompub.store module needs also a refactoring to make it more robust and transparent. Currently there's a bit of magic going on.
  • externalize the feed handler class from the amplee.atompub.collection module and split the class to make it more versatile
  • move the amplee.comparer module to amplee.utils.comparer

Necessary improvements

  • Support for Python 3
  • The indexers are now first class citizen and should undertake a serious code review
  • Allow easy adding and removing of indexes to a collection
  • Make the creation of indexes potentially more standardized via a XPath indexer
  • Sorting of indexes (ie the default could be app:edited since that is what AtomPub? prescribes)
  • Data structure selection for storage of the index (heap for the last updated index, tree/hash for an atom:id index)

Useful improvements

  • the graph package should be extended in many more use cases (Does this imply the atom threading extensions? If so, this is potentially applicable/implementable via indexes)
  • the opensearch support should be made more useful

Deprecating

  • the INI loader will quite likely be deprecated in that release

Looking into

Eric's Thoughts

Index Thoughts

In Bright Content, the indexes are the primary means of getting entries from the collection. We do this because it makes the Collection (ie the collection object) simply involved in organizing entries instead of being responsible for creating feeds. This was practical because the feed creation can involve a wide variety of requirements such as specific xml:base situations, XSLT processing instructions, content filtering, etc. A good example is the index page of a blog. You have some limit of entries that are shown. This is essentially just a query to an index that keeps a sorted list of the entries by atom:updated. This is compared to Bright Content's Annotation service, where the index is on the Atom Threading Extension and many entries are expected for the same key.

Bright Content Integration

In Bright Content there is a layered approach to saving an entry. There is a filter that is essentially applied to entries going in and out of Amplee in order to provide specific information specific to the site. I mention this because the filtering mechanism allowed for a slightly simpler CRUD interface than the default Amplee API. I'm not arguing it is better, but it might help to consider how adding new entries can be made easier. In other words, we have a store API for working with the store that sits on top of Amplee. It might be helpful to consider how the Amplee API could be made slightly closer to the Bright Content API. Likewise, it might be even better to make the Amplee API more robust so that the filtering mechanism could essentially be done in Amplee via simple functions instead of the rather involved objects that are currently necessary.