Any news Paul?

On Saturday, November 19, 2016 at 7:16:31 PM UTC+1, Paul Dragoonis wrote:
>
> Hi Guys,
>
> I'm busy with my 3 children over the weekend so I'll be back on on wagon 
> on Monday.
>
> To clarify: what I've been working on is a HTTP Router specification, that 
> uses HTTP Messages standard, and the PSR Middleware standard.
>
> Speak on Monday.
>
> Many thanks,
> Paul
>
>
> On Sat, Nov 19, 2016 at 6:12 PM, Woody Gilk <woody...@gmail.com 
> <javascript:>> wrote:
>
>> Larry,
>>
>> I think this may be a difference, or lack of clarity, with language. My 
>> interpretation is that this would be an HTTP Router proposal that would use 
>> HTTP Messages. My feeling is that this area is definitely open to 
>> standardization, as there are many "routing" packages that effectively do 
>> the same thing. 
>>
>> That said, I am not necessarily convinced that a callable is the correct 
>> target. My only concern with allowing a "mixed" type is that it cannot be 
>> strongly typed at the interface level.
>>
>> --
>> Woody Gilk
>> http://about.me/shadowhand
>>
>> On Sat, Nov 19, 2016 at 11:49 AM, Larry Garfield <la...@garfieldtech.com 
>> <javascript:>> wrote:
>>
>>> Background: My primary experience with routing systems is the conversion 
>>> of the Drupal 7 menu/routing system to the Drupal 8 Symfony-based routing 
>>> system, and realizing the issues with the way most systems seem to do 
>>> routing today. :-)
>>>
>>> I am quite skeptical about a routing PSR at this point.  Routing could 
>>> be based on a wide variety of inputs, not just the URL.  Not even just the 
>>> request, although conceptually the non-request data (likely derived from 
>>> it, but also including DB calls) could be added to the attributes array for 
>>> later access.  Even then, producing "a callable" may also be limiting, as 
>>> I've been questioning some of the decision we made in Drupal to allow 
>>> arbitrary callables as a route handler (controller).
>>>
>>> At this point I remain unconvinced that a Routing PSR would be viable 
>>> unless it was super-trivial.  Even a Route definition object would be hard 
>>> to standardize; Drupal has a lot more there than Symfony does, and we're 
>>> based on the same underlying libraries.
>>>
>>> I've not looked at what Expressive is doing or what Paul is proposing, 
>>> but at this point it doesn't feel like an area with enough "natural 
>>> standardization" for a PSR to be viable.
>>>
>>> --Larry Garfield
>>>
>>> On 11/19/2016 11:51 AM, Cees-Jan Kiewiet wrote:
>>>
>>> Same here, would be very interested to see what Paul has in mind for a 
>>> routing PSR 
>>>
>>> On Sat, Nov 19, 2016 at 5:18 AM, Woody Gilk <woody...@gmail.com 
>>> <javascript:>> wrote:
>>>
>>>> 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 <drag...@gmail.com 
>>>> <javascript:>> 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" <damianop...@gmail.com 
>>>>> <javascript:>> 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 <benjam...@gmail.com 
>>>>>> <javascript:>> wrote:
>>>>>>
>>>>>>> Hey Hari, 
>>>>>>>
>>>>>>> On 18 Nov 2016, at 06:27, Hari K T <ktha...@gmail.com <javascript:>> 
>>>>>>> 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.
>>>>>>>
>>>>>>
>>> -- 
>>> 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+u...@googlegroups.com <javascript:>.
>>> To post to this group, send email to php...@googlegroups.com 
>>> <javascript:>.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/php-fig/94ac60a2-02ce-8332-5778-59f0011c8c20%40garfieldtech.com
>>>  
>>> <https://groups.google.com/d/msgid/php-fig/94ac60a2-02ce-8332-5778-59f0011c8c20%40garfieldtech.com?utm_medium=email&utm_source=footer>
>>> .
>>> 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+u...@googlegroups.com <javascript:>.
>> To post to this group, send email to php...@googlegroups.com 
>> <javascript:>.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/php-fig/CAGOJM6%2BXGKXqpzHy1Z%3D45QmyuhCbcHkt%3DFQ5HzCKy3Ui09ER7A%40mail.gmail.com
>>  
>> <https://groups.google.com/d/msgid/php-fig/CAGOJM6%2BXGKXqpzHy1Z%3D45QmyuhCbcHkt%3DFQ5HzCKy3Ui09ER7A%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>>
>> 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/d90b3d4e-910f-4c3b-a051-ab423f00d400%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to