Skip to content

[2.1] Resource watcher component #391

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 36 commits into from

Conversation

everzet
Copy link
Contributor

@everzet everzet commented Mar 25, 2011

As we've talked in this PR: #256, i've created new Symfony2 component with ability to track resource changes (both files and directories) with 2 basic strategies:

  • Inotify
  • Recursive state checking

Component supports them both and use best one by default (if inotify available - it will be used).
Usage example: https://gist.github.com/1406938

@avalanche123
Copy link
Contributor

👍

*
* @param Event $event
*/
public function handles(Event $event)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should probably be renamed to supports to be consistent with other parts of the framework.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

agree. Changed!

@fabpot
Copy link
Member

fabpot commented Mar 25, 2011

Do we need a standalone component or does it belong to the Config one?

@everzet
Copy link
Contributor Author

everzet commented Mar 25, 2011

I don't think it belongs to Config component. If we had separate Resource component with FileResource and DirectoryResource in it, then ResourceWatcher definetly would have to be part of it. But as part of Config it doesn't make sense to me, cuz it has almost nothing to do with configs itself - ResourceWatcher's functionality is more general.

@fabpot
Copy link
Member

fabpot commented Mar 28, 2011

This feature will be considered for 2.1.

Tell me if there is anything we can do in the current code to ease this addition.

@everzet
Copy link
Contributor Author

everzet commented Mar 28, 2011

Fair enough :-) So, i will keep this PR opened to not forget about it?

@everzet
Copy link
Contributor Author

everzet commented Mar 28, 2011

The one possible change i would propose is moving *Resource-classes into separate Resource component. Because i really don't think, that resources belongs only to Config component - they used in many places and with ResourceWatcher would make sense as standalone filesystem abstraction component. What do you think?

@stof
Copy link
Member

stof commented Sep 4, 2011

@everzet @fabpot what is the status of this PR ?

@stof
Copy link
Member

stof commented Oct 16, 2011

@fabpot @everzet up

@everzet
Copy link
Contributor Author

everzet commented Oct 24, 2011

@stof needs some things to be fixed and merged. Hopefully will be able to work on it next week :-/

@stof
Copy link
Member

stof commented Nov 11, 2011

@everzet any news ?

@everzet
Copy link
Contributor Author

everzet commented Nov 13, 2011

@stof too busy with move preparations. Will try to update this PR in the train to Nantes ;-)

@simensen
Copy link
Contributor

The one possible change i would propose is moving *Resource-classes into separate Resource component. Because i really don't think, that resources belongs only to Config component - they used in many places and with ResourceWatcher would make sense as standalone filesystem abstraction component. What do you think?

I actually like this idea. My first pass at trying to figure out the Config component had me wondering why the Resource stuff was in there and not in a more generic place. There are a lot of things there that could be useful in a generic sense that don't have anything to do with configuration other than the fact that Config uses it to do its work.

@stof
Copy link
Member

stof commented Nov 17, 2011

@simensen When introducing the Config component, there was not all the Config\Definition stuff. Only the parts related to loading some resources.

@everzet
Copy link
Contributor Author

everzet commented Nov 21, 2011

Almost finished huge refactoring of RecursiveIterator and it's testing on top of rebased API. Will finish this PR thursday-friday.

@everzet
Copy link
Contributor Author

everzet commented Nov 30, 2011

There's a discussion about using EventDispatcher inside this component:
https://gist.github.com/1406938

@everzet
Copy link
Contributor Author

everzet commented Nov 30, 2011

We've agreed on EventDispatcher integration and trackingID parameter for track() (https://gist.github.com/1406938#gistcomment-66197). Anyone have thoughts?

@fabpot
Copy link
Member

fabpot commented Dec 5, 2011

@everzet: I have fixed some small issues here: everzet:resource-watcher-component...PR-391

@fabpot
Copy link
Member

fabpot commented Dec 5, 2011

I've just tested inotify support and there are some issues. I will have to investigate further.

@everzet
Copy link
Contributor Author

everzet commented Dec 5, 2011

@fabpot ok. I'll merge your changes this evening.

@everzet
Copy link
Contributor Author

everzet commented Dec 6, 2011

Merged.

@stof
Copy link
Member

stof commented Dec 12, 2011

@everzet @fabpot what's the state of this PR ?

@fabpot
Copy link
Member

fabpot commented Dec 13, 2011

I have tested it and it works fine. I still need to work on it to be sure that the features are the same for both the plain PHP implementation and the inotify implementation (I fear that this is not the case right now).

@fabpot
Copy link
Member

fabpot commented Dec 30, 2011

After working a bit more with the code, it's definitely not ready for merge. Before merging, we need to work on the following topics:

  • add more tests for the Trackers (to be sure that all implementation work in the same way) -- I have added the basic structure in the symfony/PR-291 branch.
  • probably change/tweak the current Event names based on the ones from inotify (http://en.wikipedia.org/wiki/Inotify)
  • add support for the EventDispatcher as mentioned above

@everzet
Copy link
Contributor Author

everzet commented Dec 30, 2011

@fabpot agree. Will work on EventDispatcher integration and events refactoring.

@burn2delete
Copy link

Just wondering if this has been updated to work wirth 2.1 yet? Or if it will even get in? I see alot of potential for a component like this!!!

@alvarezmario
Copy link
Contributor

@everzet said on twitter the he will try to finish the component, to be included in the 2.1 release and @fabpot was agree. So I guess we just have to wait.

@dlsniper
Copy link
Contributor

I could help with coding of this component if needed, someone like @fabpot or @everzet please let me know what's left to do for this and if I should do anything for it.

Kind regards.

@stof
Copy link
Member

stof commented Apr 4, 2012

@everzet the branch needs to be rebased as it conflicts. And tests needs to be moved.

@everzet @fabpot what is missing here to be able to merge it ?

@everzet
Copy link
Contributor Author

everzet commented Apr 4, 2012

@stof multiplatform test suite, EventDispatcher integration and event instances refactoring

i'll try to finish/rebase it this week

@everzet
Copy link
Contributor Author

everzet commented Apr 16, 2012

Closed if favor of newly created #3961

@everzet everzet closed this Apr 16, 2012
jderusse pushed a commit to jderusse/symfony that referenced this pull request Mar 30, 2020
Update version constraint on simplesamlphp/simplesamlphp/2018-12-20.yaml
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.