ext:ev should be optional ...

[kaystrobach]

it's a very uncommon library and most people won't be able to use unleash if we rely on it.

It's used here currently:

• src/Metrics.php:80
• src/Metrics.php:82
• src/Repository.php:68
• src/Repository.php:70

Also i do not see the value given by this library for our small usecase here.

[asiby]

It is used for having an event loop that periodically fetches data from the unleash API. It is needed. I don't see how you can use unleash without it or without something else that does the same thing.

[kaystrobach]

But which php application runs for such a long time? Normally it’s just running for one request then its shutdown.

New request means completly new bootstrap.

There are not that much applications using php similar to a servlet from tomcat ... And ev is not that common, for the above reasons, so the question is, if that edge case makes sense.

You may suggest the installation of ev, but it should not be mandatory.

[ivarconr]

I have been thinking more about this. I think this library should rely on a "store-abstraction" and provide various providers for that (redis, memcached, file-based).

Then the question is how to fetch toggles data in to the store. I can think of multiple options:

• do the cost at the expense of a use-request when cache-time > max.
• have a cron-job request update at given interval

What do you think?

[kaystrobach]

from my pov there are even more options:

1. if the app is deployed fetch the current state of the flags
2. if the app is running periodically fetch the data

for the second point the implementation depends on the app.

if the app has a background task, then use it an pull the data in the background, and just access the data in the app

if there is no background task, it might be needed to fetch the data in the frontend.

so from my pov the library should only ship the api to fetch and read the feature toggles. This should include a StorageInterface.

The whole pulling, updating timing is up to the application developer in my opinion

[kaystrobach]

and by the way the interface to store the data should be PSR-16 or PSR-6 then you can suggest a cahe backend for storing the data, but you would not need to do it yourself.

• https://packagist.org/?query=psr-16

Example implementation:

• https://packagist.org/packages/naroga/redis-cache
• https://packagist.org/packages/yiisoft/cache-memcached
• https://packagist.org/packages/gpolverini/apcu-cache

[kaystrobach]

Also this would dramatically reduce the complexity of that library, as just the fetching has to be implemented. All the other stuff should be delegated to the developer of the interfacing software.

[ivarconr]

This sounds like the right direction to me.

[asiby]

But which php application runs for such a long time? Normally it’s just running for one request then its shutdown.

New request means completly new bootstrap.

There are not that much applications using php similar to a servlet from tomcat ... And ev is not that common, for the above reasons, so the question is, if that edge case makes sense.

You may suggest the installation of ev, but it should not be mandatory.

With the ev extension, there are lots of PHP codes running now as "daemons" or in the background under the controller of like applications like Supervisor for instance. People are being outraged about it, but it doesn't really matter. I myself have used PHP long running script in at least three occasions:

1. A VoIP callback queue system
2. A VoIP real time billing engine for Asterisk PBX
3. A websocket backend server based on http://socketo.me/
4. etc.

These have been running in the server for at least 3 years without any issue. I only needed to restart them after performing some code update.

To ensure the availability of the script, I used Supervisor (http://supervisord.org/).

The old days when PHP was just a scripting language that would run from start to finish with a maximum execution time are over.

When it comes to the Unleash PHP client, I am 1,000,000% with @kaystrobach. The client should simply make it easy for each application developer to implement his/her own fetching approach. I believe that in its current state, this repo already has what it takes to allow the creation of a alternative client script that could be used as a cron job. The frequency of the cron job could be the responsibility of each deployment. Also, IMHO, a 15s refresh time might not be necessary and could even be increased.

[neclimdul]

Seems like what's being described is this is setup for an incredibly niche market. Sure php can support long running processes. The Drupal community ran an IRC bot for years on like php 4 and 5 so yeah nothing new there. But that's what like 0.01% of php installs?

Seems like maybe the audience for this project isn't really clear. Or maybe it is but its very clear its just for a very small group of people and someone else needs to write a client for the larger php community?

[ivarconr]

Seems like maybe the audience for this project isn't really clear. Or maybe it is but its very clear its just for a very small group of people and someone else needs to write a client for the larger php community?

Spot on @neclimdul. There are already a few PHP implementations (see the docs), but none seems to really be de-facto yet.