Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

More specific hook name(s) #11

Open
stuartpb opened this issue Apr 12, 2015 · 1 comment
Open

More specific hook name(s) #11

stuartpb opened this issue Apr 12, 2015 · 1 comment

Comments

@stuartpb
Copy link
Member

As touched upon in #10.

This would use more specific names to denote the different types of field.

I was thinking a plugin could upgrade old formats to new formats by calling, say, timestamped-app-logs and inserting the source "(unknown):", but that wouldn't work for plugins that do define timestamped-sourced-app-logs unless you either did:

  • plugin-reading trickery, which isn't strictly prohibited but is kind of "unsporting"
  • not allowing duplicate timestamps, which breaks multi-line messages and coincidences and all kinds of things, don't do that

so basically with traditional hook semantics, plugins that don't implement the "right" hook (outputting the right format) will get passed over, which is fine with me (and doing the trickery, for situations that (for some reason) can't rectify the problem the way that doesn't bend Plushu's conventions, is ok, kind of like "plushu-read-post-command-opts").

Timestamp could maybe be "millisecond-timestamped", although now we are making a really verbose hook name

@stuartpb
Copy link
Member Author

The timestamp precision doesn't really need to be specified if all timestamps adhere to the ISO format, which (apart from the "y10k" problem of four-digit years) will sort properly, indefinitely, with interpolation for any reasonably-precise timestamps.

per the y10k problem (as inherently manifest in the ISO standard), not to tempt fate (ala y2k, which unlike y10k was well within the life expectancies of its architects), and apologies to Long Now, but by the year 10000 this will probably not be the most pressing issue. (I'd honestly be disappointed if humanity doesn't move on from the Gregorian calendar in the next 8000 years.)

(and if your setup really needs to handle years of 5+ digits, because you're doing some kind of test projections or something, you can make an alternative implementation of the logs plugin that applies a numeric sort first.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant