Re: Routing PSR

[Woody Gilk]

And if you have anything ready to share, I'd be interested to see it.

--
Woody Gilk
http://about.me/shadowhand

On Fri, Nov 18, 2016 at 3:54 PM, Paul Dragoonis  wrote:

> Hello everyone,
>
> I have been waiting to announce this until after I finish with PSR16, but
> there's no time like the present.
>
> I have been working on the routing PSR for some time now, given my passion
> and experience at integrating 5 different routers into PPI Framework Engine.
>
> I have spoke with a few others about this over the past while i.e: MWOP
> and others.
>
> I would be happy to push forward this PSR, by way of Editor, by partnering
> up with someone (MWOP?), since we both have the experience at building
> routing interop engines.
>
> On the basis that someone is willing to sponsor me.
>
> What do we say, is it time to release the cracken ?
>
> Many thanks,
> Paul
>
> On 18 Nov 2016 1:01 p.m., "Damiano Petrungaro" <
> damianopetrung...@gmail.com> wrote:
>
>> What do you think about an interface that will be used by RouterInterface
>> for dispatch an event using a specific method?
>> In this way the dispatching implementation will be bounded inside a
>> single RouterInterface (so we could imagine different RouterInterfaces and
>> everyone will have a RouterDispatcherInterface implemented).
>>
>> It's ok to put the dispatching is somewhere else on the implementation
>> level, but i would like to put it inside to PSR.
>>
>> On Fri, Nov 18, 2016 at 7:06 AM Benni Mack 
>> wrote:
>>
>>> Hey Hari,
>>>
>>> On 18 Nov 2016, at 06:27, Hari K T  wrote:
>>>
>>> I believe , we should allow Router to do one thing, finding / matching
>>> the route, generating the route.
>>>
>>> Well, I think it should exactly do one thing - namely finding/match the
>>> route. The generation is IMHO separate, and belongs to a route generator or
>>> even URI/URL generator.
>>>
>>> I agree, dispatching is somewhere else on the implementation level...
>>>
>>> Best,
>>> Benni.
>>>
>>> -- TYPO3 Core Team Leader
>>> Support the project: http://typo3.org/donate/
>>>
>>> --
>>> You received this message because you are subscribed to a topic in the
>>> Google Groups "PHP Framework Interoperability Group" group.
>>> To unsubscribe from this topic, visit https://groups.google.com/d/to
>>> pic/php-fig/Fj0QoGB1xLU/unsubscribe.
>>> To unsubscribe from this group and all its topics, send an email to
>>> php-fig+unsubscr...@googlegroups.com.
>>> To post to this group, send email to php-fig@googlegroups.com.
>>> To view this discussion on the web visit https://groups.google.com/d/ms
>>> gid/php-fig/A8BB6ABD-75E9-4678-9180-F6EE02FA2A4E%40gmail.com
>>> 
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "PHP Framework Interoperability Group" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to php-fig+unsubscr...@googlegroups.com.
>> To post to this group, send email to php-fig@googlegroups.com.
>> To view this discussion on the web visit https://groups.google.com/d/ms
>> gid/php-fig/CAOOfSh5-QJYg%3D77HVqDT5pHo5tuymc3vAsKrQm93SW%
>> 3DqKMMzYQ%40mail.gmail.com
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> You received this message because you are subscribed to the Google Groups
> "PHP Framework Interoperability Group" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to php-fig+unsubscr...@googlegroups.com.
> To post to this group, send email to php-fig@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/php-fig/CAKxcST9KiOSi1auXTNgxxU5mP1-_X4Rr4xEfwQC4UgZcrnpaBA%40mail.
> gmail.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "PHP 
Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to php-fig+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/CAGOJM6KzoEZtcCems%3Dh9GVFCRNQtFVc%2BiVW3Kk70ziEWkijOYw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [REVIEW] PSR-16 Simple Cache

[Paul Dragoonis]

Hey,

Just wanted to say thanks everyone for the compliments and for the
constructive feedback.

If there's any more clarifications in the spec that you feel are *not*
tight enough please continue to raise here or make a PR so we can review it.

Many thanks,
Paul

On Fri, Nov 18, 2016 at 4:21 PM, Nicolas Grekas 
wrote:

> Hi,
>
> PSR-6 makes it very clear that the expiration date/interval is really a
> maximum and that implementations are free to make the actual item removal
> happen anytime before.
> Actually, memcached kind of proved that *for the cache use case*, it can
> be verify effective to let the backend clean items use LRU or similar.
> If PSR-6, or 16 now, would have added a requirement for storages to be
> able to store items that never expires, that would have immediately
> disqualified these strategies and related backends.
>
> Which means to me eveything is already fine for the cache use case.
>
> But this also means that PSR-6/16 are NOT fine for non-cache related use
> cases (e.g. session storage on PSR-6 is a BAD idea exactly because of this).
>
> Regards,
> Nicolas
>
>
> 2016-11-18 4:54 GMT-05:00 Jordi Boggiano :
>
>> I will try to add it to the meta document or maybe add more text to the
>> spec regarding this default expiration. I think that's the best way to make
>> people aware of it.
>>
>> That said, the symfony cache I mentioned for example, is a PSR-6
>> implementation, and will most likely implement PSR-16, while letting you
>> have items that don't expire if you use NULL. You just don't get that
>> guarantee at the spec level, I see that.
>>
>> Cheers
>>
>> On 17/11/2016 21:21, Andrew Carter wrote:
>>
>>> I don't agree with the decision, but I understand the trade off.
>>>
>>> What we're trading is the ability to set a default value in the cache
>>> configuration at the cost of not having an interoperable way for
>>> developers to create items which don't expire.
>>>
>>> From what I can tell, the PSR-6 API that we are both replacing and
>>> trying to maintain compatibility with (?) is the only cache that
>>> operates in this manner. Most other caches operate with a NULL or 0 TTL
>>> corresponding to an entry that doesn't have a natural expiry time: apc
>>> , memcache
>>> , redis
>>> , xcache
>>> , doctrine
>>> >> /latest/reference/caching.html#saving>,
>>>
>>> the symfony one you mentioned, etc..
>>>
>>> This is my last post on the subject, but I'd like whoever calls the vote
>>> to make sure that this decision and the existence of our discussion has
>>> been made clear to the voting members. I'm not sure if there's any
>>> requirement for the voting threads to draw attention to this - but I
>>> think that would be a good precedent to set if not.
>>>
>>> My last post on the subject as I think we understand each other, just
>>> disagree on the outcome.
>>>
>>> Cheers,
>>>
>>> Andrew
>>>
>>> On Thursday, November 17, 2016 at 7:09:15 PM UTC, Jordi Boggiano wrote:
>>>
>>> I see what you mean, but down the line it doesn't actually matter as
>>> it
>>> is merely a cache.
>>>
>>> You can never rely on anything you store in there being there when
>>> you
>>> want to read it again, no matter what expiration you set. The backend
>>> might be full and wiping stuff early, etc. All you can do is
>>> *request*
>>> that something be stored for a given amount of time.
>>>
>>> Given that fact I think that the null as it is now is kinda ok, it
>>> lets
>>> an application developer if they so wish configure their lib to make
>>> all
>>> cache entries expire after X hours by default, or they can say no
>>> actually keep everything forever unless otherwise specified, or if
>>> you
>>> have specific needs as a library author you can give specific
>>> expiration
>>> times. It adds a tiny bit of control for the app developer, and
>>> doesn't
>>> really remove anything from lib developers as they can anyway not
>>> rely
>>> on any guarantee from the cache.
>>>
>>> Does this make sense to you?
>>>
>>> Cheers,
>>> Jordi
>>>
>>>   On 17/11/2016 18:43, Andrew Carter wrote:
>>> > Not sure I fully understand that - as a user I can't rely on common
>>> > sense implementations doing it right. If it's not part of the
>>> standard,
>>> > I can't guarantee it as a feature and I can't use it.
>>> >
>>> > My only course of action for using that feature would be tightly
>>> > coupling to a cache library that did support items which don't
>>> expire,
>>> > and losing interoperability (as I have done in the past).
>>> >
>>> > On Wednesday, November 16, 2016 at 4:15:21 PM UTC, Jordi Boggiano
>>> wrote:
>>> >

Re: Routing PSR

[Woody Gilk]

It seems like the people are ready for it.

On Fri, Nov 18, 2016, 15:54 Paul Dragoonis  wrote:

> Hello everyone,
>
> I have been waiting to announce this until after I finish with PSR16, but
> there's no time like the present.
>
> I have been working on the routing PSR for some time now, given my passion
> and experience at integrating 5 different routers into PPI Framework Engine.
>
> I have spoke with a few others about this over the past while i.e: MWOP
> and others.
>
> I would be happy to push forward this PSR, by way of Editor, by partnering
> up with someone (MWOP?), since we both have the experience at building
> routing interop engines.
>
> On the basis that someone is willing to sponsor me.
>
> What do we say, is it time to release the cracken ?
>
> Many thanks,
> Paul
>
> On 18 Nov 2016 1:01 p.m., "Damiano Petrungaro" <
> damianopetrung...@gmail.com> wrote:
>
> What do you think about an interface that will be used by RouterInterface
> for dispatch an event using a specific method?
> In this way the dispatching implementation will be bounded inside a single
> RouterInterface (so we could imagine different RouterInterfaces and
> everyone will have a RouterDispatcherInterface implemented).
>
> It's ok to put the dispatching is somewhere else on the implementation
> level, but i would like to put it inside to PSR.
>
> On Fri, Nov 18, 2016 at 7:06 AM Benni Mack 
> wrote:
>
> Hey Hari,
>
> On 18 Nov 2016, at 06:27, Hari K T  wrote:
>
> I believe , we should allow Router to do one thing, finding / matching the
> route, generating the route.
>
> Well, I think it should exactly do one thing - namely finding/match the
> route. The generation is IMHO separate, and belongs to a route generator or
> even URI/URL generator.
>
> I agree, dispatching is somewhere else on the implementation level...
>
> Best,
> Benni.
>
> -- TYPO3 Core Team Leader
> Support the project: http://typo3.org/donate/
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "PHP Framework Interoperability Group" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/php-fig/Fj0QoGB1xLU/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> php-fig+unsubscr...@googlegroups.com.
> To post to this group, send email to php-fig@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/php-fig/A8BB6ABD-75E9-4678-9180-F6EE02FA2A4E%40gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google Groups
> "PHP Framework Interoperability Group" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to php-fig+unsubscr...@googlegroups.com.
> To post to this group, send email to php-fig@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/php-fig/CAOOfSh5-QJYg%3D77HVqDT5pHo5tuymc3vAsKrQm93SW%3DqKMMzYQ%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google Groups
> "PHP Framework Interoperability Group" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to php-fig+unsubscr...@googlegroups.com.
> To post to this group, send email to php-fig@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/php-fig/CAKxcST9KiOSi1auXTNgxxU5mP1-_X4Rr4xEfwQC4UgZcrnpaBA%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
-- 

Woody Gilk
http://about.me/shadowhand

-- 
You received this message because you are subscribed to the Google Groups "PHP 
Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to php-fig+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/CAGOJM6LjcOCuw6fJT-UBTnFJDZNwvwkc_ubfhyDbNicXX5b%3DRQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Routing PSR

[Paul Dragoonis]

Hello everyone,

I have been waiting to announce this until after I finish with PSR16, but
there's no time like the present.

I have been working on the routing PSR for some time now, given my passion
and experience at integrating 5 different routers into PPI Framework Engine.

I have spoke with a few others about this over the past while i.e: MWOP and
others.

I would be happy to push forward this PSR, by way of Editor, by partnering
up with someone (MWOP?), since we both have the experience at building
routing interop engines.

On the basis that someone is willing to sponsor me.

What do we say, is it time to release the cracken ?

Many thanks,
Paul

On 18 Nov 2016 1:01 p.m., "Damiano Petrungaro" 
wrote:

> What do you think about an interface that will be used by RouterInterface
> for dispatch an event using a specific method?
> In this way the dispatching implementation will be bounded inside a single
> RouterInterface (so we could imagine different RouterInterfaces and
> everyone will have a RouterDispatcherInterface implemented).
>
> It's ok to put the dispatching is somewhere else on the implementation
> level, but i would like to put it inside to PSR.
>
> On Fri, Nov 18, 2016 at 7:06 AM Benni Mack 
> wrote:
>
>> Hey Hari,
>>
>> On 18 Nov 2016, at 06:27, Hari K T  wrote:
>>
>> I believe , we should allow Router to do one thing, finding / matching
>> the route, generating the route.
>>
>> Well, I think it should exactly do one thing - namely finding/match the
>> route. The generation is IMHO separate, and belongs to a route generator or
>> even URI/URL generator.
>>
>> I agree, dispatching is somewhere else on the implementation level...
>>
>> Best,
>> Benni.
>>
>> -- TYPO3 Core Team Leader
>> Support the project: http://typo3.org/donate/
>>
>> --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "PHP Framework Interoperability Group" group.
>> To unsubscribe from this topic, visit https://groups.google.com/d/
>> topic/php-fig/Fj0QoGB1xLU/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> php-fig+unsubscr...@googlegroups.com.
>> To post to this group, send email to php-fig@googlegroups.com.
>> To view this discussion on the web visit https://groups.google.com/d/
>> msgid/php-fig/A8BB6ABD-75E9-4678-9180-F6EE02FA2A4E%40gmail.com
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> You received this message because you are subscribed to the Google Groups
> "PHP Framework Interoperability Group" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to php-fig+unsubscr...@googlegroups.com.
> To post to this group, send email to php-fig@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/php-fig/CAOOfSh5-QJYg%3D77HVqDT5pHo5tuymc3vAsKrQm93S
> W%3DqKMMzYQ%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "PHP 
Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to php-fig+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/CAKxcST9KiOSi1auXTNgxxU5mP1-_X4Rr4xEfwQC4UgZcrnpaBA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [REVIEW] PSR-16 Simple Cache

[Nicolas Grekas]

Hi,

PSR-6 makes it very clear that the expiration date/interval is really a
maximum and that implementations are free to make the actual item removal
happen anytime before.
Actually, memcached kind of proved that *for the cache use case*, it can be
verify effective to let the backend clean items use LRU or similar.
If PSR-6, or 16 now, would have added a requirement for storages to be able
to store items that never expires, that would have immediately disqualified
these strategies and related backends.

Which means to me eveything is already fine for the cache use case.

But this also means that PSR-6/16 are NOT fine for non-cache related use
cases (e.g. session storage on PSR-6 is a BAD idea exactly because of this).

Regards,
Nicolas


2016-11-18 4:54 GMT-05:00 Jordi Boggiano :

> I will try to add it to the meta document or maybe add more text to the
> spec regarding this default expiration. I think that's the best way to make
> people aware of it.
>
> That said, the symfony cache I mentioned for example, is a PSR-6
> implementation, and will most likely implement PSR-16, while letting you
> have items that don't expire if you use NULL. You just don't get that
> guarantee at the spec level, I see that.
>
> Cheers
>
> On 17/11/2016 21:21, Andrew Carter wrote:
>
>> I don't agree with the decision, but I understand the trade off.
>>
>> What we're trading is the ability to set a default value in the cache
>> configuration at the cost of not having an interoperable way for
>> developers to create items which don't expire.
>>
>> From what I can tell, the PSR-6 API that we are both replacing and
>> trying to maintain compatibility with (?) is the only cache that
>> operates in this manner. Most other caches operate with a NULL or 0 TTL
>> corresponding to an entry that doesn't have a natural expiry time: apc
>> , memcache
>> , redis
>> , xcache
>> , doctrine
>> > en/latest/reference/caching.html#saving>,
>>
>> the symfony one you mentioned, etc..
>>
>> This is my last post on the subject, but I'd like whoever calls the vote
>> to make sure that this decision and the existence of our discussion has
>> been made clear to the voting members. I'm not sure if there's any
>> requirement for the voting threads to draw attention to this - but I
>> think that would be a good precedent to set if not.
>>
>> My last post on the subject as I think we understand each other, just
>> disagree on the outcome.
>>
>> Cheers,
>>
>> Andrew
>>
>> On Thursday, November 17, 2016 at 7:09:15 PM UTC, Jordi Boggiano wrote:
>>
>> I see what you mean, but down the line it doesn't actually matter as
>> it
>> is merely a cache.
>>
>> You can never rely on anything you store in there being there when you
>> want to read it again, no matter what expiration you set. The backend
>> might be full and wiping stuff early, etc. All you can do is *request*
>> that something be stored for a given amount of time.
>>
>> Given that fact I think that the null as it is now is kinda ok, it
>> lets
>> an application developer if they so wish configure their lib to make
>> all
>> cache entries expire after X hours by default, or they can say no
>> actually keep everything forever unless otherwise specified, or if you
>> have specific needs as a library author you can give specific
>> expiration
>> times. It adds a tiny bit of control for the app developer, and
>> doesn't
>> really remove anything from lib developers as they can anyway not rely
>> on any guarantee from the cache.
>>
>> Does this make sense to you?
>>
>> Cheers,
>> Jordi
>>
>>   On 17/11/2016 18:43, Andrew Carter wrote:
>> > Not sure I fully understand that - as a user I can't rely on common
>> > sense implementations doing it right. If it's not part of the
>> standard,
>> > I can't guarantee it as a feature and I can't use it.
>> >
>> > My only course of action for using that feature would be tightly
>> > coupling to a cache library that did support items which don't
>> expire,
>> > and losing interoperability (as I have done in the past).
>> >
>> > On Wednesday, November 16, 2016 at 4:15:21 PM UTC, Jordi Boggiano
>> wrote:
>> >
>> > This was carried over from PSR-6 tbh, and my understanding is
>> that "an
>> > Implementing Library MAY use a configured default duration"
>> means you
>> > can very well treat null as "do not expire ever".
>> >
>> > If you read the symfony cache docs for example [1], it shows
>> that by
>> > default they treat it that way, and I'd expect others do that
>> too but I
>> > havent' researched in depth.
>> >
>>   

Re: [REVIEW] PSR-16 Simple Cache

[Jordi Boggiano]

I will try to add it to the meta document or maybe add more text to the 
spec regarding this default expiration. I think that's the best way to 
make people aware of it.


That said, the symfony cache I mentioned for example, is a PSR-6 
implementation, and will most likely implement PSR-16, while letting you 
have items that don't expire if you use NULL. You just don't get that 
guarantee at the spec level, I see that.


Cheers

On 17/11/2016 21:21, Andrew Carter wrote:

I don't agree with the decision, but I understand the trade off.

What we're trading is the ability to set a default value in the cache
configuration at the cost of not having an interoperable way for
developers to create items which don't expire.

From what I can tell, the PSR-6 API that we are both replacing and
trying to maintain compatibility with (?) is the only cache that
operates in this manner. Most other caches operate with a NULL or 0 TTL
corresponding to an entry that doesn't have a natural expiry time: apc
, memcache
, redis
, xcache
, doctrine
,
the symfony one you mentioned, etc..

This is my last post on the subject, but I'd like whoever calls the vote
to make sure that this decision and the existence of our discussion has
been made clear to the voting members. I'm not sure if there's any
requirement for the voting threads to draw attention to this - but I
think that would be a good precedent to set if not.

My last post on the subject as I think we understand each other, just
disagree on the outcome.

Cheers,

Andrew

On Thursday, November 17, 2016 at 7:09:15 PM UTC, Jordi Boggiano wrote:

I see what you mean, but down the line it doesn't actually matter as it
is merely a cache.

You can never rely on anything you store in there being there when you
want to read it again, no matter what expiration you set. The backend
might be full and wiping stuff early, etc. All you can do is *request*
that something be stored for a given amount of time.

Given that fact I think that the null as it is now is kinda ok, it lets
an application developer if they so wish configure their lib to make
all
cache entries expire after X hours by default, or they can say no
actually keep everything forever unless otherwise specified, or if you
have specific needs as a library author you can give specific
expiration
times. It adds a tiny bit of control for the app developer, and doesn't
really remove anything from lib developers as they can anyway not rely
on any guarantee from the cache.

Does this make sense to you?

Cheers,
Jordi

  On 17/11/2016 18:43, Andrew Carter wrote:
> Not sure I fully understand that - as a user I can't rely on common
> sense implementations doing it right. If it's not part of the
standard,
> I can't guarantee it as a feature and I can't use it.
>
> My only course of action for using that feature would be tightly
> coupling to a cache library that did support items which don't
expire,
> and losing interoperability (as I have done in the past).
>
> On Wednesday, November 16, 2016 at 4:15:21 PM UTC, Jordi Boggiano
wrote:
>
> This was carried over from PSR-6 tbh, and my understanding is
that "an
> Implementing Library MAY use a configured default duration"
means you
> can very well treat null as "do not expire ever".
>
> If you read the symfony cache docs for example [1], it shows
that by
> default they treat it that way, and I'd expect others do that
too but I
> havent' researched in depth.
>
> As such I am ok leaving it as is because the common-sense
> implementations will do it right, and it doesn't warrant
breaking away
> from PSR-6 IMO.
>
> Cheers
>
> [1]
>

https://symfony.com/doc/current/components/cache/cache_items.html#cache-item-expiration



>

>

>
>
> On 16/11/2016 17:03, Andrew Carter wrote:
> > Good work.
> >
> > One thing that always bothered me from a user perspective
was not
> being
> > able to put an item in the cache that doesn't expire (different
> from a
> > default expiration time). Having to create times really far in
> advance
> > is messy, and you never know if you're going to run into
2038 bugs