-
Notifications
You must be signed in to change notification settings - Fork 8
Goals and Non Goals
Table of Contents
These guidelines will be used to determine how SimplePie NG gets built, which features get accepted, and where we spend our time and attention.
A minimum-level of knowledge about PHP and its ecosystem are expected. Users should understand the difference between Unit and Integration testing, how Composer works, PHP Namespaces, Types (including type casting, type hinting, return types, and nullables), and general PHP-isms.
Our code linter and static analysis tools enforce PSR-1, PSR-2, PSR-12, and other best practices. Logging adheres to PSR-3. Autoloading and file structure adheres to PSR-4. PHPDoc docblocks adhere to PSR-5 (Draft). Caching will adhere to PSR-6 and PSR-16. Feeds are provided to SimplePie NG using PSR-7 streams.
SimplePie NG should expose the data in the feed, without determining whether or not that data is right or wrong. It should adhere to the rules of XML, JSON, and HTML, while making the allowances for real-world feeds that it can without breaking compatibility for other feeds. It should take hints from the feed specification about how to handle the data it encounters (e.g., Atom 1.0 defines one <author> per <entry>, so we will not look for more than one) but it does not validate the data it finds (e.g., that an author's email address is a real email address).
There is no “core” or “built-in” feed format support. Middleware must exist for every feed format that is supported, and there should be a 1:1 relationship between a specification and its middleware (i.e., one middleware should not add support for multiple feed formats).
We want SimplePie NG to be as fast as it can possibly be. We should use performant PHP calls, be intelligent about the efficiency of our algorithms, and run regular benchmarks to ensure that we are maintaining our performance.
We want SimplePie NG to be as memory-efficient as it can possibly be. We want to keep a low overhead, and use memory responsibly. For example, memoization is a high-leverage form of memory usage. We allow some amount of memory to be used responsibly in order to enable better performance.
We also want to enable predictable, consistent memory usage. We should see linear increases (Oⁿ) in memory usage as more feeds (e.g., XML nodes and their content, JSON files) are added — not exponential memory growth. We also want to ensure that well-engineered consumption of SimplePie NG should enable consistent memory usage.
These are things that we explicitly don't care about. If someone suggests that we should do a thing because of one of these reasons, we will point out that we absolutely don't care about these reasons.
This is an entirely new project, whose API has been designed 13 years after the original API. While some of the core concepts should be familiar, API similarities should be considered coincidental.
You should expect that that the API won't be the same as SimplePie 1.x.
WordPress targets an entirely different kind of user than SimplePie NG. WordPress also targets a lower version of PHP than SimplePie NG does. WordPress users tend to not be predominantly PHP software engineers. For these reasons and more, WordPress support is a non-goal.
You should expect that that SimplePie NG will not work with WordPress. Be pleasantly surprised if it does, and don't expect it to continue.
We're starting with support for 7.2 and moving forward from there. As new versions of PHP are released, expect that we will adopt them as soon as our dependencies do. As the project matures, we will look into SLAs and LTS releases. We're not there yet.
You should expect that SimplePie NG will never work with PHP 7.1 and older. See PHP Version Support for more information.
Managed, shared hosting providers typically lack support for the latest software. They often have too many users on the same box (over-selling, over-provisioning). Many times they lack basics such as Zend OpCache. There can be a great many variables when it comes to supporting shared hosts that it isn't worth the support burden.
You should expect that you will need to use a VPS (e.g., Linode, Digital Ocean, Amazon Lightsail), an infrastructure service (e.g., Amazon Web Services, Google Cloud Platform, Microsoft Azure), or a cloud platform service (e.g., Heroku) where you can manage your own packages and environment.
Oh, or Docker.
Project Information
Usage
Internals
Contributing