structlog revisited.  Discuss proposed q API.  Who can make time to work on pieces of it?

A PoC will be put into the incubator with minimum required pipeline stages.  Intention is for others to contribute additional pipes / filters based on their own use cases.

For the most part, the pipes will be manipulating a q dictionary.  The standard keys would be: `timestamp, `level, `event.

Would be good to start standardizing names for keys.  Possibilities include: `hostname, `username, `workspace_statistics .

To ensure interoperability of logging producers and consumers, a pipeline stage might check for nonstandard tags and throw an error (in development mode, anyway).

Further discussion can take place on the mail group.

Start with "Include".  Still needs some iterating; basic version would be easy.

"InitHook" creates a framework which later modules can build on, so would be nice if that went out on the earlier side.

Debug utilities which can get the arity of lambdas / projections are also available, but probably lower priority.

kdb used to infer the schema based on the earliest date partition.  Later on, this changed to latest date partition.  This can result in an inconsistent view if accessed while tables are being written for latest date.  Some hack around this by writing a partition at an arbitrarily chosen date in the future.  A schema.q standard might avoid this.

A document of what is considered a "consistent HDB" is something kdb+ WG can work on.  There are ways to modify kdb to ignore empty table segments.  This might evolve into a kdb+ WG best practices document or even code.