Some event sources will definitely only run once.

For instance, once we've done on@delay "00:00:01" {} we will never subscribe to that particular timer again.

MaxTriggerCount 1 should automatically be passed in all one-time event sources.

This should generate an event when the location has changed, using:

$exectutionContext.SessionState.InvokeCommand.LocationChangedAction

Hard-coded event source registration is tedious, and goes against the architectural grain.

Any @Name.ps1 file should count as an event source.

On@CommandNotFound

On@CommandNotFound is a very useful new event source in Eventful.

As the name implies, it's generated whenever a command is not found.

How CommandNotFound works

The PowerShell language supports having a command CommandNotFound handler.

It's available in:

$executionContext.SessionState.InvokeCommand.CommandNotFound 

The generator simply sets that handler to generate an event with the source identifier PowerShell.CommandNotFound.

Eventful has many event sources already, but there are many more events in .NET to explore.

This should have a -Pre and -Post switch parameter to clarify which of these two eventhandlers should be assigned:

$executionContext.SessionState.InvokeCommand.PostCommandLookupAction
$executionContext.SessionState.InvokeCommand.PreCommandLookupAction

Eventing should be supported in PipeScript via Transpilers, or integrated into the language.

References found in:

• Eventful.tests.ps1

Watch-Event currently checks only the current directory and its source directory for event sources. While this is faster, it requires registration of event sources within a .psd1 to discover them. This is suboptimal. Therefore, performance should lose this trade-off and any file named @nameofsource should be searched for -Recrusively.

We should be easily able to import events, and optionally -Resend them.

This can be done by slightly tweaking the parameters on Send-Event to add the alias 'SourceEventArgs' to -EventArgs

Eventful should support sponsorship.

These two parameters could be passed to Register-Object/EngineEvent

-MaxTriggerCount is especially useful, as it unregisters the event subscriber after N events (which is very useful when something will only happen once).

Accordingly, both parameters should be able to be defaulted based off of a [Reflection.AssemblyMetadata] attributes of the event source, or a property on the returned object.

An event channel should be the combination of several possible events / conditions. It should also (probably) have a polling frequency.

Eventful is cool and small and should integrate with more ecosystems to become more useful.

Hello,
This is a feature request to extend Eventful to incorporate a process to send data to Azure's Event Hub. When Eventful creates an event, this data point can be sent to AZ's EventHub for later or real-time processing.

Send-Event does not send EventArgs, because New-Event has EventArguments as the parameter name.

We should able to easily export events.