Re: Custom extensions to META.yml
On 3/1/07, David Golden [EMAIL PROTECTED] wrote: I've had some requests for a mechanism for module authors to indicate whether or not they want to be copied on module test emails generated by CPAN::Reporter (particularly for passing reports). This seems like the kind of thing that should go in the module META.yml. I really like this idea. Is there a de facto standard for custom extensions to META.yml? (I didn't see one in the spec.) An example might be fields beginning with a capital letter or X-foo style extensions. E.g. I don't think there is a standard for these extensions to META.yml, but I am convinced there must be sensible ways to do it when we need them. Note that it precludes the idea of a complete and closed schema for the META.yml specification. X-cc-author: no Alternatively, what would people think about adding a field in META.yml like notes for this kind of extra information. E.g.: notes: cc_author: no My suggestion would be to have a section 'hints' in META.yml (that would look like the 'notes' you suggested, only with a name which indicates the section contents is actually suggestions rather than rules to be followed). This section could be subdivided into tools -- meaning the author is giving hints to various tools involved in the processing of distributions. These tools could be named generically. For instance, 'test_reporter' could be used in CPAN::Reporter case. Why not the module name itself? So that someone else could implement its test reporter and use the same information without being ashamed because that information was meant for some other piece of code ;-) This way, the section to be added to META.yml would be hints: test_reporter: cc_author: no Of course, we would like to see all the variants we grow used to, like cc_author: no cc_author: yes cc_author: fail cc_author: ok # this author likes to receive only good news Thanks in advance for your thoughts. Thank you. Adriano Ferreira.
Module proposal: Test::Timer
Hello,
I have just finished a module I need at a gig with a client. The
module is called Test::Timer, it resembles, Test::Benchmark a lot,
apart from it is much simpler.
It exports a single method: time_ok
Which takes a body of code, a threshold and a name;
time_ok( sub { sleep(1); }, 5, 'Passing test' );
time_ok( sub { sleep(10); }, 5, 'Non-passing test' );
If the body of code does not finish within the specified threshold
the test fails.
The module is primarily syntactic sugar, mmm sugar, but it scratches
my itch, since we have a lot of back-end API's, which do not respond
within the thresholds of our web framework.
So my question is: is this module already on CPAN, or something
similar (better), or should I put mine there?
I have several things which I need to improve and investigate,
especially for the body of code part and the code is alpha, but in
the spirit of
open-source I think it would be a good idea to share it - the
alternative is a life under corporate revision control in darkness
and seclusion.
Looking forward to hearing from you guys,
jonasbn aka. [EMAIL PROTECTED]
Re: Custom extensions to META.yml
On 3/1/07, David Golden [EMAIL PROTECTED] wrote: I've had some requests for a mechanism for module authors to indicate whether or not they want to be copied on module test emails generated by CPAN::Reporter (particularly for passing reports). This seems like the kind of thing that should go in the module META.yml. Is there a de facto standard for custom extensions to META.yml? (I didn't see one in the spec.) An example might be fields beginning with a capital letter or X-foo style extensions. E.g. X-cc-author: no Alternatively, what would people think about adding a field in META.yml like notes for this kind of extra information. E.g.: notes: cc_author: no I would prefer the second option because it is more modular. However, there should be a way to add things to it easily when preparing the META.yml. Regards, Shlomi Fish Thanks in advance for your thoughts. David -- -- Shlomi Fish http://www.shlomifish.org/ If his programming is anything like his philosophising, he would find 10 imaginary bugs in the Hello World program.
Re: Custom extensions to META.yml
On 3/1/07, Adriano Ferreira [EMAIL PROTECTED] wrote: My suggestion would be to have a section 'hints' in META.yml (that I think that's an excellent name for the section I proposed. Of course, we would like to see all the variants we grow used to, like cc_author: no cc_author: yes cc_author: fail cc_author: ok # this author likes to receive only good news My thiought was that it would take the same specification as CPAN::Reporter uses in the configuration file -- though quoting would be required for the advanced forms: cc_author: 'fail/na/unknown:yes pass:no' David
Custom extensions to META.yml
I've had some requests for a mechanism for module authors to indicate whether or not they want to be copied on module test emails generated by CPAN::Reporter (particularly for passing reports). This seems like the kind of thing that should go in the module META.yml. Is there a de facto standard for custom extensions to META.yml? (I didn't see one in the spec.) An example might be fields beginning with a capital letter or X-foo style extensions. E.g. X-cc-author: no Alternatively, what would people think about adding a field in META.yml like notes for this kind of extra information. E.g.: notes: cc_author: no Thanks in advance for your thoughts. David
Re: Custom extensions to META.yml
David Golden writes: Is there a de facto standard for custom extensions to META.yml? (I didn't see one in the spec.) An example might be fields beginning with a capital letter or X-foo style extensions. E.g. X-cc-author: no Does putting X- in front of such fields really help? X- isn't really a namespace; having 2 people separately inventing the X-Hair-Colour field isn't any better than them clashing over Hair-Colour. And if your X-cc-author field takes off can you really envisage a separate CC-Author field being created? Having them both in existence would be really confusing. So in practice all the X- achieves is making users have to remember which field names have an X- in front of them and which don't! Alternatively, what would people think about adding a field in META.yml like notes for this kind of extra information. E.g.: notes: cc_author: no Similar kind of problem: notes is very generic (like other or misc), such that it's arbitrary which is a 'proper' field and which is a 'notes' field. Can't we just start using cc-author as a field, then if it takes off get it blessed as part of the official spec? Smylers
Re: Custom extensions to META.yml
* Smylers [EMAIL PROTECTED] [2007-03-01 21:45]: Can't we just start using cc-author as a field, then if it takes off get it blessed as part of the official spec? Then how do you tell whether `bastract` is a typo or extension field? I think adding a `hints` field which is a hash of hashes, where the key in `hints` acts as a namespace, is the best proposition so far. This would also reduce the following problem to near irrelevance: Does putting X- in front of such fields really help? X- isn't really a namespace; having 2 people separately inventing the X-Hair-Colour field isn't any better than them clashing over Hair-Colour. If `notes` is a hash of hashes, then the only clash potential is among keys in the upper level hash, which should be about as clash-prone as distro names on the CPAN – admittedly not an inherently collision-free system, but one that works well enough in practice. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Module proposal: Syslog::DevKit
I'm in the process of implementing a large scale central syslog
architecture based on syslog-ng and POE. syslog-ng buys me compliance
while I finish building my custom correlation engine with POE.
I wanted a way to deal with syslog messages as they came in from the
network, as well as messages from flat files (with the preamble
stripped). There's a ton of syslog modules on CPAN, so I'd prefer to
not clutter up the namespace if I don't have to. I just couldn't find a
good fit for this idea that I'm developing, so perhaps through communal
wisdom someone will beat my into submitting to another module.
Here's the 0.01 interface:
SYNOPSIS
I wanted a very simple log parser for network based syslog input.
Nothing existed that simply took a line and returned a hash ref all
parsed out.
use Parse::Syslog::Line qw(syslog_parse_line);
my $href = syslog_parse_line( $msg );
#
# $href = {
# preamble= '13',
# priority= 'notice',
# priority_int= 5,
# facility= 'user',
# facility_int= 8,
# date= '-MM-DD',
# time= 'HH::MM:SS',
# datetime_str= '-MM-DD HH:MM:SS',
# datetime_obj= new DateTime(), # If
# installed
# datetime_raw= 'Feb 17 11:12:13'
# host_raw= 'hostname', #
# Hostname as it appeared in the message
# host= 'hostname', #
# Hostname without domain
# domain = 'blah.com', # if
# provided
# program_raw =
# 'sshd(blah)[pid]',
# program_name= 'sshd',
# program_sub = 'pam_unix',
# program_pid = 20345,
# content = 'the rest of the
# message'
# message = 'program[pid]:
# the rest of the message',
# message_raw = 'The message as
# it was passed',
# };
...
As I've been working on this project, I've found that it might be useful
to have a module that was also capable of using SQL::Abstract to
generate tables, selects, and inserts based off the syslog input, so my
initial namespace and simple Exporter design is probly getting an OO
overhaul to support things like hostname resolution, query building, and
sub modules for pluggable handling of certain message types (like the
SyslogScan::* name space). Only SyslogScan seems to be primarily
focussed solely on sendmail messages.
The closest to what I'm imagining is Net::Dev::Tools::Syslog. However,
I'm not interested in mimicing a syslog server so I'm not sure my
proposed namespace works either.
Perhaps Syslog::Ax(e?) or Syslog::Parser would be better?
Comments? Rants?
--
Brad Lhotsky
Re: Custom extensions to META.yml
Following David Goldens' observations, Adriano Ferreira wrote: This way, the section to be added to META.yml would be hints: test_reporter: cc_author: no This seems a very pragmatic solution to a problem, however given recent posts, it seems to be a solution in search of approval - is there a meta.yml owner / committee / interest group - at least a mailing list? Steve
