Re: [symfony-devs] Re: [RFC] Cache component

[liuggio]

Few words because I'm a little bit lost,
cache is polysemic word, and for me unify caching is a great task
but in order to clean (my) chaos could be great start from the usage this
new component should have.

Is possible to have a short and draft description of this new cache
component with Goal and API?

starting from the *@vicb* ticket (
https://github.com/symfony/symfony/issues/1513

*Must:*
support Cache Validator
support Cache Annotations reader
support Cache Doctrine Bundle

*Should:*
have Cache factories

and

What about
- Http caching?
- php-fig?
- Twig, yes I know that is better to have filesystem + Opcode but why not
unifying all the component cache?





On Sun, Mar 24, 2013 at 10:39 PM, Cameron Junge
wrote:

> +1 from me on the ArrayAccess interface - that makes it so easy to use!
>
>
> On Monday, March 25, 2013 3:08:17 AM UTC+13, Kinn Coelho Julião wrote:
>
>> I believe we can simplify rather than complicate.
>> Once the FIG decide something related to interface, and developers
>> implement the interface, SF2 can use any caching layer since the interface
>> will be standard.
>> One solution that I like and is very simple, is to implement the
>> ArrayAccess as in the example below: https://github.com/PHPFluent/**
>> Cache/blob/master/src/**PHPFluent/Cache/Cache.php//With
>>  the interface, it will be not just doctrine, but
>> "FIGCacheInterfaceSomething"
>>
>> It is so simplistic, that it may fail in the future... anyway, people can
>> extend it to create it owns
>>
>> I would love to have something like this in Symfony:
>>
>>  $cache = new Cache;
>> $userList cache = $['userList'];
>> / /
>> ...
>> $cache = new Cache;
>> $room  = $cache["chatRoom_ {$ parameter}"];
>>
>> As you can see, it is simple and useful... everybody knows array(or must
>> know, what is PHP without array?)... You don't need to learn a new API for
>> this, it is a simples and pretty array that can take advantages of cool
>> enhancements done in PHP5.4 and PHP5.5 beta1 =]
>>
>>
>>
>> 2013/3/23 Amy Stephen 
>>
>>>
>>>
>>> On Saturday, March 23, 2013 7:12:49 PM UTC-5, Guilherme Blanco wrote:


 I am a huge evangelist of OS and I think PSR should release their own
 code that everyone would reuse. I can't see better argument to probably
 have same implementation being ported to PHP itself. But for now, I think
 we have in FIG brililant minds that could help and their effort would also
 help everyone.

 There is a FIG poll about this very question we are asked to use for
>>> providing feedback https://groups.google.com/d/**
>>> msg/php-fig/3hPX9N0eru4/**vnE3hHzqGkkJ
>>>
>>> Personally, I disagree with FIG releasing code as I prefer to see ways
>>> of leveraging project solutions between projects.
>>>
>>> However, either for or against, there is a place to share those opinions
>>> on the link above, but it's likely off topic to what Symfony decides is
>>> appropriate for the Symfony project. =)
>>>
>>> --
>>> --
>>> If you want to report a vulnerability issue on Symfony, please read the
>>> procedure on http://symfony.com/security
>>>
>>> You received this message because you are subscribed to the Google
>>> Groups "symfony developers" group.
>>> To post to this group, send email to symfon...@googlegroups.com
>>>
>>> To unsubscribe from this group, send email to
>>> symfony-devs...@**googlegroups.com
>>>
>>> For more options, visit this group at
>>> http://groups.google.com/**group/symfony-devs?hl=en
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "Symfony developers" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to symfony-devs...@**googlegroups.com.
>>>
>>> For more options, visit 
>>> https://groups.google.com/**groups/opt_out
>>> .
>>>
>>>
>>>
>>
>>
>>
>> --
>> *-*
>> * Kinn Coelho Julião*
>> **
>> * kinncj.com.br
>>About.me/kinncj
>> *
>> *-*
>>
>  --
> --
> If you want to report a vulnerability issue on Symfony, please read the
> procedure on http://symfony.com/security
>
> You received this message because you are subscribed to the Google
> Groups "symfony developers" group.
> To post to this group, send email to symfony-devs@googlegroups.com
> To unsubscribe from this group, send email to
> symfony-devs+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/symfony-devs?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Symfony developers" group.
> To unsubscribe from this group and stop receiving email

Re: [symfony-devs] Re: [RFC] Cache component

[Cameron Junge]

+1 from me on the ArrayAccess interface - that makes it so easy to use!

On Monday, March 25, 2013 3:08:17 AM UTC+13, Kinn Coelho Julião wrote:
>
> I believe we can simplify rather than complicate.
> Once the FIG decide something related to interface, and developers 
> implement the interface, SF2 can use any caching layer since the interface 
> will be standard.
> One solution that I like and is very simple, is to implement the 
> ArrayAccess as in the example below: 
> https://github.com/PHPFluent/Cache/blob/master/src/PHPFluent/Cache/Cache.php//With
>  the interface, it will be not just doctrine, but 
> "FIGCacheInterfaceSomething"
>
> It is so simplistic, that it may fail in the future... anyway, people can 
> extend it to create it owns
>
> I would love to have something like this in Symfony:
>
>  $cache = new Cache;
> $userList cache = $['userList'];
> / /
> ...
> $cache = new Cache;
> $room  = $cache["chatRoom_ {$ parameter}"];
>
> As you can see, it is simple and useful... everybody knows array(or must 
> know, what is PHP without array?)... You don't need to learn a new API for 
> this, it is a simples and pretty array that can take advantages of cool 
> enhancements done in PHP5.4 and PHP5.5 beta1 =]
>
>
>
> 2013/3/23 Amy Stephen >
>
>>
>>
>> On Saturday, March 23, 2013 7:12:49 PM UTC-5, Guilherme Blanco wrote:
>>>
>>>
>>> I am a huge evangelist of OS and I think PSR should release their own 
>>> code that everyone would reuse. I can't see better argument to probably 
>>> have same implementation being ported to PHP itself. But for now, I think 
>>> we have in FIG brililant minds that could help and their effort would also 
>>> help everyone.
>>>
>>> There is a FIG poll about this very question we are asked to use for 
>> providing feedback 
>> https://groups.google.com/d/msg/php-fig/3hPX9N0eru4/vnE3hHzqGkkJ
>>
>> Personally, I disagree with FIG releasing code as I prefer to see ways of 
>> leveraging project solutions between projects.
>>
>> However, either for or against, there is a place to share those opinions 
>> on the link above, but it's likely off topic to what Symfony decides is 
>> appropriate for the Symfony project. =)
>>  
>> -- 
>> -- 
>> If you want to report a vulnerability issue on Symfony, please read the 
>> procedure on http://symfony.com/security
>>  
>> You received this message because you are subscribed to the Google
>> Groups "symfony developers" group.
>> To post to this group, send email to symfon...@googlegroups.com
>> To unsubscribe from this group, send email to
>> symfony-devs...@googlegroups.com 
>> For more options, visit this group at
>> http://groups.google.com/group/symfony-devs?hl=en
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "Symfony developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to symfony-devs...@googlegroups.com .
>> For more options, visit https://groups.google.com/groups/opt_out.
>>  
>>  
>>
>
>
>
> -- 
> *-*
> * Kinn Coelho Julião*
> **
> * kinncj.com.br
>About.me/kinncj
> *
> *-*
>  

-- 
-- 
If you want to report a vulnerability issue on Symfony, please read the 
procedure on http://symfony.com/security

You received this message because you are subscribed to the Google
Groups "symfony developers" group.
To post to this group, send email to symfony-devs@googlegroups.com
To unsubscribe from this group, send email to
symfony-devs+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/symfony-devs?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Symfony developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to symfony-devs+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [symfony-devs] Re: [RFC] Cache component

[Kinn Julião]

I believe we can simplify rather than complicate.
Once the FIG decide something related to interface, and developers
implement the interface, SF2 can use any caching layer since the interface
will be standard.
One solution that I like and is very simple, is to implement the
ArrayAccess as in the example below:
https://github.com/PHPFluent/Cache/blob/master/src/PHPFluent/Cache/Cache.php//With
the interface, it will be not just doctrine, but
"FIGCacheInterfaceSomething"

It is so simplistic, that it may fail in the future... anyway, people can
extend it to create it owns

I would love to have something like this in Symfony:

$cache = new Cache;
$userList cache = $['userList'];
/ /
...
$cache = new Cache;
$room  = $cache["chatRoom_ {$ parameter}"];

As you can see, it is simple and useful... everybody knows array(or must
know, what is PHP without array?)... You don't need to learn a new API for
this, it is a simples and pretty array that can take advantages of cool
enhancements done in PHP5.4 and PHP5.5 beta1 =]



2013/3/23 Amy Stephen 

>
>
> On Saturday, March 23, 2013 7:12:49 PM UTC-5, Guilherme Blanco wrote:
>>
>>
>> I am a huge evangelist of OS and I think PSR should release their own
>> code that everyone would reuse. I can't see better argument to probably
>> have same implementation being ported to PHP itself. But for now, I think
>> we have in FIG brililant minds that could help and their effort would also
>> help everyone.
>>
>> There is a FIG poll about this very question we are asked to use for
> providing feedback
> https://groups.google.com/d/msg/php-fig/3hPX9N0eru4/vnE3hHzqGkkJ
>
> Personally, I disagree with FIG releasing code as I prefer to see ways of
> leveraging project solutions between projects.
>
> However, either for or against, there is a place to share those opinions
> on the link above, but it's likely off topic to what Symfony decides is
> appropriate for the Symfony project. =)
>
> --
> --
> If you want to report a vulnerability issue on Symfony, please read the
> procedure on http://symfony.com/security
>
> You received this message because you are subscribed to the Google
> Groups "symfony developers" group.
> To post to this group, send email to symfony-devs@googlegroups.com
> To unsubscribe from this group, send email to
> symfony-devs+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/symfony-devs?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Symfony developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to symfony-devs+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>



-- 
*-*
* Kinn Coelho Julião*
**
* kinncj.com.br
   About.me/kinncj
*
*-*

-- 
-- 
If you want to report a vulnerability issue on Symfony, please read the 
procedure on http://symfony.com/security

You received this message because you are subscribed to the Google
Groups "symfony developers" group.
To post to this group, send email to symfony-devs@googlegroups.com
To unsubscribe from this group, send email to
symfony-devs+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/symfony-devs?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Symfony developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to symfony-devs+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [symfony-devs] Re: [RFC] Cache component

[Amy Stephen]

On Saturday, March 23, 2013 7:12:49 PM UTC-5, Guilherme Blanco wrote:
>
>
> I am a huge evangelist of OS and I think PSR should release their own code 
> that everyone would reuse. I can't see better argument to probably have 
> same implementation being ported to PHP itself. But for now, I think we 
> have in FIG brililant minds that could help and their effort would also 
> help everyone.
>
> There is a FIG poll about this very question we are asked to use for 
providing feedback 
https://groups.google.com/d/msg/php-fig/3hPX9N0eru4/vnE3hHzqGkkJ

Personally, I disagree with FIG releasing code as I prefer to see ways of 
leveraging project solutions between projects.

However, either for or against, there is a place to share those opinions on 
the link above, but it's likely off topic to what Symfony decides is 
appropriate for the Symfony project. =)

-- 
-- 
If you want to report a vulnerability issue on Symfony, please read the 
procedure on http://symfony.com/security

You received this message because you are subscribed to the Google
Groups "symfony developers" group.
To post to this group, send email to symfony-devs@googlegroups.com
To unsubscribe from this group, send email to
symfony-devs+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/symfony-devs?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Symfony developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to symfony-devs+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [symfony-devs] Re: [RFC] Cache component

[guilhermebla...@gmail.com]

Matt, you probably get me wrong.
I mentioned I was tired of personal preference was about all lately "tabs
vs spaces" on php-fig. =)

Personally I'd think if everyone thinks PSR is the way to go for everyone
to release a possible cache implementation, I'd love to help there and
deprecate Doctrine\Cache. But if FIG focus only on interfaces (which is
another perspective from many), then I'll work my best to have a solid,
stable component that is PSR compliant on Doctrine.

The only thing I feel bad is to see people reinventing the wheel on every
project because A they don't like the implementation, B because of license
constraints, C because they want their own namespace or D company
limitations.

I am a huge evangelist of OS and I think PSR should release their own code
that everyone would reuse. I can't see better argument to probably have
same implementation being ported to PHP itself. But for now, I think we
have in FIG brililant minds that could help and their effort would also
help everyone.


Cheers,



On Sat, Mar 23, 2013 at 7:34 PM, Matt Robinson  wrote:

> Ouch. I'd be the first to argue that my personal preference shouldn't
> decide where Symfony should go, and it's very possible (even likely) that
> my opinion is wrong, but it's not stupid. :)
>
> I never meant to suggest that we make yet another cache implementation
> completely in isolation from anything that has come before (although
> scrolling down, it could easily look like that - sorry, not my intention!)
>
> So let me rephrase and explain myself: where Symfony uses a cache backend,
> it should use the PSR Cache interface (when it's released). For
> convenience, it should also come with a component that implements that
> interface. That component should probably use Doctrine Cache as its own
> backend (it would be silly to write one from scratch). Then you can swap in
> anything that implements the PSR, just like you can replace the Symfony
> HTTP cache with Varnish, and Monolog with any other PSR-3 logger.
>
> Changing Doctrine Cache to implement the cache PSR and then using it
> directly looks to me like a trivial amount of coding, but it has wider
> implications and shouldn't be done quickly: lots of projects already use
> its current interface, and if you maintained BC by implementing both
> interfaces developers might (horribly) use methods from both, so really
> you're talking about making Doctrine Cache 3.0, not say 2.4. On the other
> hand, making a Symfony cache component that wraps the current Doctrine
> Cache with a PSR interface is very little work too and prevents the Symfony
> release schedule being held to another 3rd party project's timescales (and
> Doctrine's release schedule being pressured by Symfony). That's what I
> meant by a Symfony cache component.
>
> Kind regards,
>
> -- Matt Robinson
>
> On 23 Mar 2013, at 19:42, "guilhermebla...@gmail.com" <
> guilhermebla...@gmail.com> wrote:
>
> @Matt, having pattern and wildcard cannot work since most cache providers
> to not expose API for this type of usage. =(
>
> I personally think Doctrine Cache is good enough as a start, but of course
> there're updates that we could do.
> If FIG would want to provide a common interface or even a common code for
> everyone to use it, I'd love to give a hand implementing it.
> Personally I feel extremely tired nowadays of current threads rolling out
> there as people are discussing (sorry, but..( stupid personal preferences
> instead of common goal.
>
> Cheers,
>
>
> On Sat, Mar 23, 2013 at 3:03 PM, Matt Robinson  wrote:
>
>> I'd love to see FIG standardise a cache interface and for Symfony to have
>> an exemplary implementation of it, but that doesn't necessarily mean it
>> needs to be a Symfony component if something better already exists.
>>
>> Personally though I don't think Doctrine Cache is that something. At
>> least not yet. It doesn't quite feel "Symfonic" (weird, since it's already
>> part of Doctrine ORM), and since its current interface has no methods in
>> common with the PSR proposal, it seems it would be more work to change it
>> (and everything that uses it) than to accept one of the PRs mentioned below
>> and document it. I could be dead wrong though; DC's support for patterns &
>> wildcards is really neat, for example, and it's a stable and well-tested
>> library as far as I can tell.
>>
>> On balance, I think I'd rather see a new Symfony Cache component.
>>
>> On 23 Mar 2013, at 17:21, Florin Patan  wrote:
>>
>> Hi Fabien,
>>
>>
>> Nice to see some activity for this.
>>
>> I think we should get this done after FIG does their job as it would help
>> the
>> community but after a long time discussing this, FIG has been quiet this
>> week.
>>
>> Maybe a fresh set of eyes from Symfony community members on the
>> FIG ML here: https://groups.google.com/forum/#!topic/php-fig/UkSWS48eEgo
>>
>> Paul did a great job in trying to summarize and get the best out of all
>> proposals for FIG and there's also the long standing propos

Re: [symfony-devs] Re: [RFC] Cache component

[Matt Robinson]

Ouch. I'd be the first to argue that my personal preference shouldn't decide 
where Symfony should go, and it's very possible (even likely) that my opinion 
is wrong, but it's not stupid. :) 

I never meant to suggest that we make yet another cache implementation 
completely in isolation from anything that has come before (although scrolling 
down, it could easily look like that - sorry, not my intention!)

So let me rephrase and explain myself: where Symfony uses a cache backend, it 
should use the PSR Cache interface (when it's released). For convenience, it 
should also come with a component that implements that interface. That 
component should probably use Doctrine Cache as its own backend (it would be 
silly to write one from scratch). Then you can swap in anything that implements 
the PSR, just like you can replace the Symfony HTTP cache with Varnish, and 
Monolog with any other PSR-3 logger. 

Changing Doctrine Cache to implement the cache PSR and then using it directly 
looks to me like a trivial amount of coding, but it has wider implications and 
shouldn't be done quickly: lots of projects already use its current interface, 
and if you maintained BC by implementing both interfaces developers might 
(horribly) use methods from both, so really you're talking about making 
Doctrine Cache 3.0, not say 2.4. On the other hand, making a Symfony cache 
component that wraps the current Doctrine Cache with a PSR interface is very 
little work too and prevents the Symfony release schedule being held to another 
3rd party project's timescales (and Doctrine's release schedule being pressured 
by Symfony). That's what I meant by a Symfony cache component. 

Kind regards,

-- Matt Robinson

On 23 Mar 2013, at 19:42, "guilhermebla...@gmail.com" 
 wrote:

> @Matt, having pattern and wildcard cannot work since most cache providers to 
> not expose API for this type of usage. =(
> 
> I personally think Doctrine Cache is good enough as a start, but of course 
> there're updates that we could do.
> If FIG would want to provide a common interface or even a common code for 
> everyone to use it, I'd love to give a hand implementing it.
> Personally I feel extremely tired nowadays of current threads rolling out 
> there as people are discussing (sorry, but..( stupid personal preferences 
> instead of common goal.
> 
> Cheers,
> 
> 
> On Sat, Mar 23, 2013 at 3:03 PM, Matt Robinson  wrote:
> I'd love to see FIG standardise a cache interface and for Symfony to have an 
> exemplary implementation of it, but that doesn't necessarily mean it needs to 
> be a Symfony component if something better already exists.
> 
> Personally though I don't think Doctrine Cache is that something. At least 
> not yet. It doesn't quite feel "Symfonic" (weird, since it's already part of 
> Doctrine ORM), and since its current interface has no methods in common with 
> the PSR proposal, it seems it would be more work to change it (and everything 
> that uses it) than to accept one of the PRs mentioned below and document it. 
> I could be dead wrong though; DC's support for patterns & wildcards is really 
> neat, for example, and it's a stable and well-tested library as far as I can 
> tell.
> 
> On balance, I think I'd rather see a new Symfony Cache component. 
> 
> On 23 Mar 2013, at 17:21, Florin Patan  wrote:
> 
>> Hi Fabien,
>> 
>> 
>> Nice to see some activity for this.
>> 
>> I think we should get this done after FIG does their job as it would help the
>> community but after a long time discussing this, FIG has been quiet this
>> week.
>> 
>> Maybe a fresh set of eyes from Symfony community members on the
>> FIG ML here: https://groups.google.com/forum/#!topic/php-fig/UkSWS48eEgo
>> 
>> Paul did a great job in trying to summarize and get the best out of all
>> proposals for FIG and there's also the long standing proposal from Robert.
>> 
>> As for Symfony2 strictly, if FIG adopts a PSR and then Doctrine makes
>> a move to become compatible with it I don't see why we couldn't rely on
>> Doctrine Cache to provide the caching layer, just like we have Monolog.
>> 
>> Have a nice weekend.
>> 
>> 
>> Best regards,
>> Florin
>> 
>> On Saturday, March 23, 2013 7:11:56 PM UTC+2, Fabien Potencier wrote:
>> Hi all, 
>> 
>> There is probably one missing component in Symfony: a cache one. There 
>> is already a ticket and 4 PRs on this topic, but I think we need to 
>> discuss what we want to do before writing any code. Also because there 
>> have been a lot of discussions already on the FIG group, so we also need 
>> to discuss what is our position about this too. 
>> 
>> I'm pretty sure that we won't have time to finish anything serious 
>> before 2.3, so we have time to get it right. 
>> 
>> For reference, here are the ticket on Symfony: 
>> 
>> https://github.com/symfony/symfony/issues/1513 
>> 
>> And the 4 PRs: 
>> 
>> https://github.com/symfony/symfony/issues/3211 
>> https://github.com/symfony/symfony/issues/3225 
>> https://github.com/symfony

Re: [symfony-devs] Re: [RFC] Cache component

[guilhermebla...@gmail.com]

@Matt, having pattern and wildcard cannot work since most cache providers
to not expose API for this type of usage. =(

I personally think Doctrine Cache is good enough as a start, but of course
there're updates that we could do.
If FIG would want to provide a common interface or even a common code for
everyone to use it, I'd love to give a hand implementing it.
Personally I feel extremely tired nowadays of current threads rolling out
there as people are discussing (sorry, but..( stupid personal preferences
instead of common goal.

Cheers,


On Sat, Mar 23, 2013 at 3:03 PM, Matt Robinson  wrote:

> I'd love to see FIG standardise a cache interface and for Symfony to have
> an exemplary implementation of it, but that doesn't necessarily mean it
> needs to be a Symfony component if something better already exists.
>
> Personally though I don't think Doctrine Cache is that something. At least
> not yet. It doesn't quite feel "Symfonic" (weird, since it's already part
> of Doctrine ORM), and since its current interface has no methods in common
> with the PSR proposal, it seems it would be more work to change it (and
> everything that uses it) than to accept one of the PRs mentioned below and
> document it. I could be dead wrong though; DC's support for patterns &
> wildcards is really neat, for example, and it's a stable and well-tested
> library as far as I can tell.
>
> On balance, I think I'd rather see a new Symfony Cache component.
>
> On 23 Mar 2013, at 17:21, Florin Patan  wrote:
>
> Hi Fabien,
>
>
> Nice to see some activity for this.
>
> I think we should get this done after FIG does their job as it would help
> the
> community but after a long time discussing this, FIG has been quiet this
> week.
>
> Maybe a fresh set of eyes from Symfony community members on the
> FIG ML here: https://groups.google.com/forum/#!topic/php-fig/UkSWS48eEgo
>
> Paul did a great job in trying to summarize and get the best out of all
> proposals for FIG and there's also the long standing proposal from Robert.
>
> As for Symfony2 strictly, if FIG adopts a PSR and then Doctrine makes
> a move to become compatible with it I don't see why we couldn't rely on
> Doctrine Cache to provide the caching layer, just like we have Monolog.
>
> Have a nice weekend.
>
>
> Best regards,
> Florin
>
> On Saturday, March 23, 2013 7:11:56 PM UTC+2, Fabien Potencier wrote:
>>
>> Hi all,
>>
>> There is probably one missing component in Symfony: a cache one. There
>> is already a ticket and 4 PRs on this topic, but I think we need to
>> discuss what we want to do before writing any code. Also because there
>> have been a lot of discussions already on the FIG group, so we also need
>> to discuss what is our position about this too.
>>
>> I'm pretty sure that we won't have time to finish anything serious
>> before 2.3, so we have time to get it right.
>>
>> For reference, here are the ticket on Symfony:
>>
>> https://github.com/symfony/symfony/issues/1513
>>
>> And the 4 PRs:
>>
>> https://github.com/symfony/symfony/issues/3211
>> https://github.com/symfony/symfony/issues/3225
>> https://github.com/symfony/symfony/issues/5902
>> https://github.com/symfony/symfony/issues/5903
>>
>> Let's start the discussion!
>>
>> Fabien
>>
>> --
>> Fabien Potencier
>> SensioLabs CEO - Symfony lead developer
>> sensiolabs.com | symfony.com | fabien.potencier.org
>> +33 1 40 99 80 80
>>
>
> --
> --
> If you want to report a vulnerability issue on Symfony, please read the
> procedure on http://symfony.com/security
>
> You received this message because you are subscribed to the Google
> Groups "symfony developers" group.
> To post to this group, send email to symfony-devs@googlegroups.com
> To unsubscribe from this group, send email to
> symfony-devs+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/symfony-devs?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Symfony developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to symfony-devs+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
>
>  --
> --
> If you want to report a vulnerability issue on Symfony, please read the
> procedure on http://symfony.com/security
>
> You received this message because you are subscribed to the Google
> Groups "symfony developers" group.
> To post to this group, send email to symfony-devs@googlegroups.com
> To unsubscribe from this group, send email to
> symfony-devs+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/symfony-devs?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Symfony developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to symfony-devs+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>

Re: [symfony-devs] Re: [RFC] Cache component

[Matt Robinson]

I'd love to see FIG standardise a cache interface and for Symfony to have an 
exemplary implementation of it, but that doesn't necessarily mean it needs to 
be a Symfony component if something better already exists.

Personally though I don't think Doctrine Cache is that something. At least not 
yet. It doesn't quite feel "Symfonic" (weird, since it's already part of 
Doctrine ORM), and since its current interface has no methods in common with 
the PSR proposal, it seems it would be more work to change it (and everything 
that uses it) than to accept one of the PRs mentioned below and document it. I 
could be dead wrong though; DC's support for patterns & wildcards is really 
neat, for example, and it's a stable and well-tested library as far as I can 
tell.

On balance, I think I'd rather see a new Symfony Cache component. 

On 23 Mar 2013, at 17:21, Florin Patan  wrote:

> Hi Fabien,
> 
> 
> Nice to see some activity for this.
> 
> I think we should get this done after FIG does their job as it would help the
> community but after a long time discussing this, FIG has been quiet this
> week.
> 
> Maybe a fresh set of eyes from Symfony community members on the
> FIG ML here: https://groups.google.com/forum/#!topic/php-fig/UkSWS48eEgo
> 
> Paul did a great job in trying to summarize and get the best out of all
> proposals for FIG and there's also the long standing proposal from Robert.
> 
> As for Symfony2 strictly, if FIG adopts a PSR and then Doctrine makes
> a move to become compatible with it I don't see why we couldn't rely on
> Doctrine Cache to provide the caching layer, just like we have Monolog.
> 
> Have a nice weekend.
> 
> 
> Best regards,
> Florin
> 
> On Saturday, March 23, 2013 7:11:56 PM UTC+2, Fabien Potencier wrote:
> Hi all, 
> 
> There is probably one missing component in Symfony: a cache one. There 
> is already a ticket and 4 PRs on this topic, but I think we need to 
> discuss what we want to do before writing any code. Also because there 
> have been a lot of discussions already on the FIG group, so we also need 
> to discuss what is our position about this too. 
> 
> I'm pretty sure that we won't have time to finish anything serious 
> before 2.3, so we have time to get it right. 
> 
> For reference, here are the ticket on Symfony: 
> 
> https://github.com/symfony/symfony/issues/1513 
> 
> And the 4 PRs: 
> 
> https://github.com/symfony/symfony/issues/3211 
> https://github.com/symfony/symfony/issues/3225 
> https://github.com/symfony/symfony/issues/5902 
> https://github.com/symfony/symfony/issues/5903 
> 
> Let's start the discussion! 
> 
> Fabien 
> 
> -- 
> Fabien Potencier 
> SensioLabs CEO - Symfony lead developer 
> sensiolabs.com | symfony.com | fabien.potencier.org 
> +33 1 40 99 80 80 
> 
> -- 
> -- 
> If you want to report a vulnerability issue on Symfony, please read the 
> procedure on http://symfony.com/security
>  
> You received this message because you are subscribed to the Google
> Groups "symfony developers" group.
> To post to this group, send email to symfony-devs@googlegroups.com
> To unsubscribe from this group, send email to
> symfony-devs+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/symfony-devs?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Symfony developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to symfony-devs+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>  
>  

-- 
-- 
If you want to report a vulnerability issue on Symfony, please read the 
procedure on http://symfony.com/security

You received this message because you are subscribed to the Google
Groups "symfony developers" group.
To post to this group, send email to symfony-devs@googlegroups.com
To unsubscribe from this group, send email to
symfony-devs+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/symfony-devs?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Symfony developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to symfony-devs+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.