date:20180313

Re: PSR-14 (Event manager)

2018-03-13 Thread Larry Garfield

Well, I've been talking about stepping forward to take over as PSR-14 Editor 
for a few weeks now.  I should probably go ahead and do it since there seems 
to be interest.

Before we start showing code, I'd prefer to step back and define the specific 
use cases we want to target.  Benni's list below is a good starting point for 
that discussion.  That would probably be some discussion in Slack or similar 
within the WG first.  I would prefer to not use a separate GitHub group but we 
can coordinate that with the secretaries.

Those who are interested in being part of an event dispatcher PSR-14 working 
group (I suggest we change the name since "manager" is so pointlessly 
generic), please ping me by email or Slack.

We also would then need another CC member to sponsor before we can formally 
open a vote to reactivate the WG.  Who's up for it?

Note: My time will be a bit scarce for the next week as I'm working for a 
political campaign, but the election is next Tuesday so win or lose I should 
have more time available at that point. :-)

--Larry Garfield

On Tuesday, March 13, 2018 9:26:40 AM CDT Barney Hanlon wrote:
> Is this the right forum for putting forward examples of our own work as
> potential candidates? I’ve been working on one under the name event interop
> (much as PSR-11 was born from) but it seems we all have similar ideas.
> Shall we start showing some code examples?
> 
> > Hey folks,
> > 
> > I've been meaning to share my feedback for quite some time on that.
> > 
> > We've looked into different implementations a lot and we (TYPO3 dev) would
> > only consider Event Manager if we're talking about immutable events. And
> > event is triggered, could have parameters, but the event itself should not
> > allow to alter parameters.
> > 
> > A classic example in our project is to change/modify values before storing
> > them in a RDMS - this is not an event. Modifying a request object is not
> > the job of an event listener. Of course, if you hand over objects as
> > parameters, it's hard to enforce that they are kept as they are.
> > Events to modifying parameters is a different pattern, and we should aim
> > to differentiate between them.
> > 
> > Once this is in the mind-set, an event (and event system) is actually very
> > simple - also ordering is not _as_ important anymore (for our use-cases).
> > However, it showed that an event system is only half of the business, and
> > that it should be accompanied by a hooking system.
> > 
> > Basically we consider three different use cases:
> > - Events (Immutable) - "Hey, I just persisted something" then we could
> > flush Caches
> > - Filters / Pipelines - "Here is some data, go and enrich it" - then we
> > could have plugins of a framework modify or add metadata to the records,
> > based on the current request.
> > - Filters / Interceptors - If one of the "listeners" actually says" no,
> > you can't do that", the following action should not be called - like a
> > permission system.
> > 
> > I'm happy to join the WG to make the PSR-14 as event manager ready,
> > however, I do believe that we should start thinking more.
> > 
> > All the best,
> > Benni.
> > 
> > On 13. Mar 2018, at 14:38, Niels Braczek  wrote:
> > 
> > Am 13.03.2018 um 10:58 schrieb Barney Hanlon:
> > 
> > I would recommend that setParam or indeed any setting of properties be out
> > of the spec. In my opinion, Events and Commands should both be immutable,
> > but people are open to implement configuration post-construction if they
> > wish. But if the spec defines these, then the spec is defining the payload
> > of them as mutable. That doesn’t strike me as a good idea.
> > 
> > 
> > +1
> > 
> > Regards,
> > Niels
> > 

-- 
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/3025774.dyY8PJcCfW%40vulcan.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: This is a digitally signed message part.

Re: PSR-14 (Event manager)

2018-03-13 Thread Barney Hanlon

Is this the right forum for putting forward examples of our own work as
potential candidates? I’ve been working on one under the name event interop
(much as PSR-11 was born from) but it seems we all have similar ideas.
Shall we start showing some code examples?

-- 
Barney Hanlon

On 13 March 2018 at 14:08:43, Benjamin Mack (benjamin.m...@gmail.com) wrote:

> Hey folks,
>
> I've been meaning to share my feedback for quite some time on that.
>
> We've looked into different implementations a lot and we (TYPO3 dev) would
> only consider Event Manager if we're talking about immutable events. And
> event is triggered, could have parameters, but the event itself should not
> allow to alter parameters.
>
> A classic example in our project is to change/modify values before storing
> them in a RDMS - this is not an event. Modifying a request object is not
> the job of an event listener. Of course, if you hand over objects as
> parameters, it's hard to enforce that they are kept as they are.
> Events to modifying parameters is a different pattern, and we should aim
> to differentiate between them.
>
> Once this is in the mind-set, an event (and event system) is actually very
> simple - also ordering is not _as_ important anymore (for our use-cases).
> However, it showed that an event system is only half of the business, and
> that it should be accompanied by a hooking system.
>
> Basically we consider three different use cases:
> - Events (Immutable) - "Hey, I just persisted something" then we could
> flush Caches
> - Filters / Pipelines - "Here is some data, go and enrich it" - then we
> could have plugins of a framework modify or add metadata to the records,
> based on the current request.
> - Filters / Interceptors - If one of the "listeners" actually says" no,
> you can't do that", the following action should not be called - like a
> permission system.
>
> I'm happy to join the WG to make the PSR-14 as event manager ready,
> however, I do believe that we should start thinking more.
>
> All the best,
> Benni.
>
> On 13. Mar 2018, at 14:38, Niels Braczek  wrote:
>
> Am 13.03.2018 um 10:58 schrieb Barney Hanlon:
>
> I would recommend that setParam or indeed any setting of properties be out
> of the spec. In my opinion, Events and Commands should both be immutable,
> but people are open to implement configuration post-construction if they
> wish. But if the spec defines these, then the spec is defining the payload
> of them as mutable. That doesn’t strike me as a good idea.
>
>
> +1
>
> Regards,
> Niels
>
> --
> | New Stars on the Horizon: GreenCape · nibralab · laJoom |
> | http://www.bsds.de · BSDS Braczek Software- und DatenSysteme |
> | Webdesign · Webhosting · e-Commerce · Joomla! Content Management |
> --
>
> --
> 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/9af851fb-a53b-8a3d-6b0c-f7b8012c98cf%40bsds.de.
>
> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> 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/EwCZ9ritJcA/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/5C39045D-3C58-44F8-ACBD-3E519BA7B869%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/CALKGMgfC0NYhiGSdnUJoWnmW6ZEo%2BfnqaMK9ORAFpD1gO%3DXm%2BA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: PSR-14 (Event manager)

2018-03-13 Thread Benjamin Mack

Hey folks,

I've been meaning to share my feedback for quite some time on that.

We've looked into different implementations a lot and we (TYPO3 dev) would only 
consider Event Manager if we're talking about immutable events. And event is 
triggered, could have parameters, but the event itself should not allow to 
alter parameters.

A classic example in our project is to change/modify values before storing them 
in a RDMS - this is not an event. Modifying a request object is not the job of 
an event listener. Of course, if you hand over objects as parameters, it's hard 
to enforce that they are kept as they are.
Events to modifying parameters is a different pattern, and we should aim to 
differentiate between them.

Once this is in the mind-set, an event (and event system) is actually very 
simple - also ordering is not _as_ important anymore (for our use-cases). 
However, it showed that an event system is only half of the business, and that 
it should be accompanied by a hooking system. 

Basically we consider three different use cases:
- Events (Immutable) - "Hey, I just persisted something" then we could flush 
Caches
- Filters / Pipelines - "Here is some data, go and enrich it" - then we could 
have plugins of a framework modify or add metadata to the records, based on the 
current request.
- Filters / Interceptors - If one of the "listeners" actually says" no, you 
can't do that", the following action should not be called - like a permission 
system.

I'm happy to join the WG to make the PSR-14 as event manager ready, however, I 
do believe that we should start thinking more.

All the best,
Benni.

> On 13. Mar 2018, at 14:38, Niels Braczek  wrote:
> 
> Am 13.03.2018 um 10:58 schrieb Barney Hanlon:
> 
>> I would recommend that setParam or indeed any setting of properties be out
>> of the spec. In my opinion, Events and Commands should both be immutable,
>> but people are open to implement configuration post-construction if they
>> wish. But if the spec defines these, then the spec is defining the payload
>> of them as mutable. That doesn’t strike me as a good idea.
> 
> +1
> 
> Regards,
> Niels
> 
> -- 
> | New Stars on the Horizon:  GreenCape  ·  nibralab  ·  laJoom |
> | http://www.bsds.de   ·   BSDS Braczek Software- und DatenSysteme |
> | Webdesign · Webhosting · e-Commerce · Joomla! Content Management |
> --
> 
> -- 
> 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/9af851fb-a53b-8a3d-6b0c-f7b8012c98cf%40bsds.de.
> 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/5C39045D-3C58-44F8-ACBD-3E519BA7B869%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: PSR-14 (Event manager)

2018-03-13 Thread Niels Braczek

Am 13.03.2018 um 10:58 schrieb Barney Hanlon:

> I would recommend that setParam or indeed any setting of properties be out
> of the spec. In my opinion, Events and Commands should both be immutable,
> but people are open to implement configuration post-construction if they
> wish. But if the spec defines these, then the spec is defining the payload
> of them as mutable. That doesn’t strike me as a good idea.

+1

Regards,
Niels

-- 
| New Stars on the Horizon:  GreenCape  ·  nibralab  ·  laJoom |
| http://www.bsds.de   ·   BSDS Braczek Software- und DatenSysteme |
| Webdesign · Webhosting · e-Commerce · Joomla! Content Management |
 --

-- 
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/9af851fb-a53b-8a3d-6b0c-f7b8012c98cf%40bsds.de.
For more options, visit https://groups.google.com/d/optout.

Re: The progress of HTTP client

2018-03-13 Thread Careen joseph



Uri uri = new Uri("...");
try
{
HttpClient client = new HttpClient();
var downloadTask = client.GetAsync(uri);

downloadTask.Progress = (result, progress) => 
{
Debug.WriteLine("===start===");
Debug.WriteLine(progress.BytesReceived);
Debug.WriteLine(progress.TotalBytesToReceive);
Debug.WriteLine("===end===");
};

var Downloadresult = await downloadTask;
Debug.WriteLine("Done: " + 
Downloadresult.StatusCode.ToString());
}
catch (Exception ex)
{
}

https://www.besanttechnologies.com/training-courses/data-warehousing-training/hadoop-training-institute-in-chennai

-- 
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/c010b93f-38c9-487e-82f3-add7c424f6b4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: PSR-14 (Event manager)

2018-03-13 Thread Barney Hanlon

I would recommend that setParam or indeed any setting of properties be out
of the spec. In my opinion, Events and Commands should both be immutable,
but people are open to implement configuration post-construction if they
wish. But if the spec defines these, then the spec is defining the payload
of them as mutable. That doesn’t strike me as a good idea.

-- 
Barney Hanlon

On 13 March 2018 at 09:04:44, Xedin Unknown (xedin.unkn...@gmail.com) wrote:

> IMHO, looks like we are nowhere with the event manager standard. There are
> a handful of implementations, most very recent. Not aware of any consumers,
> besides my code.
>
> I believe there are many things wrong with that standard. Right now, I'm
> working on a proposal of how it can be changed. Meanwhile, I am maintaining
> the interfaces in dhii/psr-14 .
> Currently super tied down with time. So much so, in fact, that I have not
> had any chance to work on the standard, which I am a part of the workgroup
> for.
>
> If any body is interested, here are my suggestions on PSR-14:
>
> EventInterface
>
>- Add `setParam()`. It is super common that parameters are set one at
>a time, by name. Right now, they must be set altogether, which is extremely
>inconvenient.
>- Add `hasParam()`. This can allow the consumer to determine whether
>something is indeed set.
>- Document what happens with `getParam()` if the param is not set.
>- Remove `setName()` and `setTarget()`. After an even is created with
>a particular name and target, nothing should be able to change this. Just
>imagine that the name is changed after the event has been dispatched. This
>is nonsensical.
>- (Optional) Remove `setParams()` and `getParams()`. The event should
>probably allow operations on one parameter at a time, similarly to
>`ContainerInterface`. Allowing *all* params to be retrieved is not
>practical, as it would in many cases require the map to be iterable. This
>is a burden on the implementation. If there needs to be an iterable list of
>something, it can be passed safely as one of the parameters.
>- (Optional) Remove `getTarget()`. Why does there need to be a target?
>Or maybe, a more appropriate name for it is "source", as this is the
>context that the event comes *from*. If it needs to be passed, and is
>optional, why not just have it be one of the parameters?
>
> EventManagerInterface
>
>- `trigger()` to accept only `EventInterface`, and not `string`. Why
>is it the concern of the event manager to normalize strings into events?
>This will make the logic simpler.
>- Remove `$argv` parameter from `trigger()`. If only `EventInterface`
>instances can be passed, this becomes redundant. Also, currently it is not
>documented what to pass in this parameter.
>- (Optional) Remove `$priority` parameter from `attach()`. With
>events, it is never clear what context this has. Priority as compared to
>what? How can it be possible to know what the other events' priorities are,
>so that I can put my event between them? This is a job for a module
>
> 
>standard, which I happen to be working on.
>
> @Barney, get in touch if you wanna help make a draft.
>
> On Tuesday, August 15, 2017 at 11:12:48 PM UTC+2, Barney Hanlon wrote:
>>
>> Hello all,
>>
>> and in my first post in this group, I thought I might query where we are
>> at with event managers (PSR-14).
>>
>> Recently, forgetting to check the FIG site, I hadn't realised there was
>> already work on this and had started work on my own implementation of an
>> Event-based standard, so that all listeners/events/dispatchers/emitters
>> can play nicely. Obviously, far happier to go with an existing trend than
>> try and reinvent a wheel. However, I'm not sure how to contribute in any
>> way as a newbie to the mailing list.
>>
>> I was inspired to sign up because I thought it would be good to debate
>> further was the setParam() in the proposal - should events be mutable after
>> instantiation, as part of the spec?
>>
>> Hoping to hear back and would love to assist in this proposal.
>>
>> --
>> Barney
>>
>> --
> 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/EwCZ9ritJcA/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/9f44f49e-9f55-42e5-b8df-aee93c874007%40googlegroups.com
> 
> .
> For more

Re: PSR-14 (Event manager)

2018-03-13 Thread Xedin Unknown

IMHO, looks like we are nowhere with the event manager standard. There are 
a handful of implementations, most very recent. Not aware of any consumers, 
besides my code.

I believe there are many things wrong with that standard. Right now, I'm 
working on a proposal of how it can be changed. Meanwhile, I am maintaining 
the interfaces in dhii/psr-14 . 
Currently super tied down with time. So much so, in fact, that I have not 
had any chance to work on the standard, which I am a part of the workgroup 
for.

If any body is interested, here are my suggestions on PSR-14:

EventInterface

   - Add `setParam()`. It is super common that parameters are set one at a 
   time, by name. Right now, they must be set altogether, which is extremely 
   inconvenient.
   - Add `hasParam()`. This can allow the consumer to determine whether 
   something is indeed set.
   - Document what happens with `getParam()` if the param is not set.
   - Remove `setName()` and `setTarget()`. After an even is created with a 
   particular name and target, nothing should be able to change this. Just 
   imagine that the name is changed after the event has been dispatched. This 
   is nonsensical.
   - (Optional) Remove `setParams()` and `getParams()`. The event should 
   probably allow operations on one parameter at a time, similarly to 
   `ContainerInterface`. Allowing *all* params to be retrieved is not 
   practical, as it would in many cases require the map to be iterable. This 
   is a burden on the implementation. If there needs to be an iterable list of 
   something, it can be passed safely as one of the parameters.
   - (Optional) Remove `getTarget()`. Why does there need to be a target? 
   Or maybe, a more appropriate name for it is "source", as this is the 
   context that the event comes *from*. If it needs to be passed, and is 
   optional, why not just have it be one of the parameters?

EventManagerInterface

   - `trigger()` to accept only `EventInterface`, and not `string`. Why is 
   it the concern of the event manager to normalize strings into events? This 
   will make the logic simpler.
   - Remove `$argv` parameter from `trigger()`. If only `EventInterface` 
   instances can be passed, this becomes redundant. Also, currently it is not 
   documented what to pass in this parameter.
   - (Optional) Remove `$priority` parameter from `attach()`. With events, 
   it is never clear what context this has. Priority as compared to what? How 
   can it be possible to know what the other events' priorities are, so that I 
   can put my event between them? This is a job for a module 
   

 
   standard, which I happen to be working on.

@Barney, get in touch if you wanna help make a draft.

On Tuesday, August 15, 2017 at 11:12:48 PM UTC+2, Barney Hanlon wrote:
>
> Hello all,
>
> and in my first post in this group, I thought I might query where we are 
> at with event managers (PSR-14).
>
> Recently, forgetting to check the FIG site, I hadn't realised there was 
> already work on this and had started work on my own implementation of an 
> Event-based standard, so that all listeners/events/dispatchers/emitters can 
> play nicely. Obviously, far happier to go with an existing trend than try 
> and reinvent a wheel. However, I'm not sure how to contribute in any way as 
> a newbie to the mailing list.
>
> I was inspired to sign up because I thought it would be good to debate 
> further was the setParam() in the proposal - should events be mutable after 
> instantiation, as part of the spec?
>
> Hoping to hear back and would love to assist in this proposal.
>
> --
> Barney
>
>

-- 
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/9f44f49e-9f55-42e5-b8df-aee93c874007%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: PSR-14 (Event manager)

Re: PSR-14 (Event manager)

Re: PSR-14 (Event manager)

Re: PSR-14 (Event manager)

Re: The progress of HTTP client

Re: PSR-14 (Event manager)

Re: PSR-14 (Event manager)

7 matches

Site Navigation

Mail list logo

Footer information