RFC - Implemenatation ideas

[liuggio]

Hi,
I like your project and we are using in production,
some ideas...

• Writer(external) and reader(web) should not share the same config file, they are conceptually different.
• The writer 'd have an interface (maybe doctrine common cache) so swapping with other mechanisms as APC/Redis/MYSQL 'll become easy related to Other DB #11
• Composerize the project vendors
• uses PSR*

what do you think?

[markstory]

Abstracting different datastores is going to be a huge amount of work, and make the project more difficult to maintain. What's the upside?

What do you see being different in the configuration files?

I'm not sure there is much of a win to use composer with only one vendor. The only thing I see it doing right now is making the installation more complicated by adding another step. If we start using more vendor libraries it might start to make sense though.

I'm currently working on refactoring some of the global functions so that they are attached to classes, or properly prefixed, this fits into PSR scope as prefixed classnames are acceptable there. When @preinheimer and I originally discussed the project we didn't want to use namespaces as that prevents people still using 5.2 from using xhgui. Was there something else you had in mind?

[jaikdean]

Support for other datastores would be useful for us. We have a few sites on scalable, load-balanced AWS setups. Having to set up, manage and maintain an EC2 instance just to run MongoDB for performance data collection isn't ideal. However, AWS provides a managed NoSQL called DynamoDB which is trivial to set up and maintenance-free.

[preinheimer]

Interesting, supporting the basic feature set on there might not be too bad, the more advanced stuff (like custom searches and reporting) might be trickier.

[markstory]

Complex queries and aggregation are always tricky in a multiple datastore solution. Building a good testsuite helps, but having multiple datastores always adds complexity.

[dennisdegreef]

I'm working on a library which has multiple datastores, but currently has not 'frontend'. I'm currently refactoring the internal data structure also keeping in mind that XHGui would work on top of the datastore adapter of Mongo. Is there any way we can work together to complete this common goal? A shared interface for datastructures inside of mongo and/or files would be awesome!

My library is link0/profiler and i'm currently working on link0/profiler#62

[markstory]

@dennisdegreef I don't see why we couldn't try and share the same mongo data structures. We'll need to figure out a way to make changes in a backwards compatible way on our side though.

[Krinkle]

1. The writer have an to swapping with other backends.

Done per #244. See also #11.

2. Use compsoer for dependencies.

Done.

3. Separate writer and reader config.

Done with https://github.com/perftools/php-profiler.

4. Use PSR*.

There will always be another PSR. But overall I don't think this matters much for XHGui since it has almost no dependencies and the ones it does have, I think, don't benefit being able to swap out (they just work), also since it's not meant to be composed with other apps as library but is itself a finished application.

If this this about autoloading PSR, it uses that now (just PSR0 for now).

If this is about coding style consistency, that isn't done yet. Could set up PHPCS in a separate ticket. I filed #299 for that now.

This ticket can be closed I think?