[NEWS]21/05/.2017 - eXpansion2 in the pipes (long pipes nothing soon)

[oliverde8]

As you know we dropped support on expansion 1; details here : viewtopic.php?f=518&t=39489

But I said on a previous topics, we did start working on the new version of eXpansion. Right now we are working on the core, or the framework as we call it.

eXpansion2 is at the moment a prototype, will it work is the question, more specifically can Symfony & Doctrine run without loosing memory for long period of times.

Yes you heard right we chose to use the Symfony as a base (right now with many things that we don't need). We did this for multiple reasons;
but mostly because dependency Injection makes life easier and SF3 has a great DI system.
Using SF comes with drawbacks we will for example never be able to load/unload plugins like eXpansion1 did, you will need to restart the controller.

There is many new things in this new version as they introduce new concepts & a new way to create plugins.

Firs of all in eXpansion2 the plugin term is used differently. What we used to call plugins will be called Bundles, using SF naming. it is those bundles that you will need to add, start & stop.

Bundles may contain :
- Data providers, these have the job of taking data from the dedicated and submit it to plugins(yes plugins).
- Plugins, will receive data from the data providers, they don't need to know what script is running.

Basically we have a timeDataProvider, this provider will send time related information such as checkpoint, map finish and such to plugins that requires it. So this provider will work for TM in a few specified scripts.
Later on someone will wish to install eXp2 on SM Obstacle, the game is the same as in TM. It's about doing the best possible time.
So he will create a new timeDataProvider (with new class & code), and put it in his bundle SmObstacleAdapterBundle.

Once this is done eXp2 will autoplug all plugins that required timeDataProvider with this new data provider
and suddenly the LocalRecords bundle(that contained a plugin requiring timeDataProvider) that didn't start because of dependency issues will start to work.

This part is done dynamically without using the SF DI for injections, as we need to be able to switch from one DataProvider to another as the admin loads a new script on the server.

We can also chain, dataProviders. Data provider requiring a plugin which requires a dataProvider.
For example LocalRecordsWidgetPlugin would need LocalRecordsDataProvider which needs LocalRecordsPlugin which needs TimeDataProvider.
So taking the example above again adding a new TimeDataProvider for obstacles will suddenly make everything work.

This part of our prototype is relatively done, we don't handle properly the current script as a part is hard coded but the hard part is done.

Another point we wish to improve upon is code quality. In eXp we saw that having 1 Plugin => 1 Listener class with chat commands and everything else in it, created huuge classes that become very hard to maintain.
In eXp2 first of all there shall be(or already is) only one class for each chat command.
Each chat command can be configured for different parameters & as we used symfony we have some very nice command options such as /admin restart --help
And all checks for chat command arguments are done with the symfony console component making it very nice to use.

For the listener classes, those are the "plugins" there is nothing preventing you do to it all in one file. But you now have the possibility to brake it apart.


There is still a lot todo & imagine. We will have a more unified front. so that it will be easier for new bundles to create grids & such. We of course have translations it's already there.
As with the use of the DI system it will be relatively easy to extend the default behaviour (Exemple : redirect chat partially to a manialink), or create a "Theme" Bundle that changes the way eXpansion feels & look.

We also wish to have less bugs and so we have put unitary tests in place from day 1.

The scary part is memory leaks, as we used a framework that wasn't meant to run as a deamon.
I know doctrine can be a wool headed fool on this subject, but I also know it should be possible to prevent it from leaking(actually caching everything).

So if all goes well maybe one day there it will be back. I really hope so we already invested quite a lot of time into it.

OOo and we already have more technical documentation then eXp1 ever had, http://mp-expansion.com