This set of modules implements Webmention, according to its W3C-defined spec as well as related best practices developed by the IndieWeb community.

About Webmention

Webmention provides a standard way for one website to inform another that someone, somewhere on the web, has published a reference to a URL under the receiver's domain. This notification travels through very short and simple HTTP POST messages that merely identify the two URLs involved: the source of the mention, and its target. The receiver of a webmention can, at its own leisure, request the HTML document found at the source URL in order to verify the mention, and also to learn more about its author and content via any Microformats2 metadata it may contain. The receiver may then proceed to do something interesting with this fetched and parsed data, such as display hyperlinked information about the mention and its author underneath its own, original content.

For example, a response published on Blog A to an article on Magazine B could result in A sending a webmention to B. (There is implied consent here, since the article on B has a <link> tag in its HTML that explicitly invites webmentions, providing an endpoint URI for them.) It would then become B's responsibility to confirm that the webpage at A really does mention the URL of B's aticle. B may then wish to represent the mention on its own site, however it deems appropriate.

About these modules

An object of the main Web::Mention class represents a single webmention instance, probably created from an incoming HTTP request, as shown in the synopsis. The object's verify() method (and, indeed, its is_verified attribute) will do the hard work of fetching the source URL's document, verifying the presence of the target URL, and parsing any Microformats2 metdata it finds in order to infer author information. The latter goes into a Web::Mention::Author object, and taken all together this should give the receiver enough information to react in some appropriate way to the mention.

This module requires Web::Microformats2, another proposed CPAN module of mine with its own PrePAN page.

Near-future versions of this module will assist with creating and sending webmentions. But receiving is the harder part (and arguably the more rewarding part as well) so I wanted to get it done first. This ended up being a depth-first adventure that resulted in my creating all of Web::Microformats2 before I could come back and finish this module, and so here we are.

Regarding the name

I'd like to hear opinions on the name. Giving it a top-level namespace of "Web" seemed natural, for the same arguments I made in Web::Microformats2's case, and then following up the way I did seemed inevitable. But is splitting the word up this way too "cute"? Or, more to the point, will it make it harder to find in CPAN searches?

Certainly "Web::Webmention" is too ugly to live, but I could be talked into e.g. "Net::Webmention" or "HTTP::Webmention" or something. Absent any argument to the contrary, I do like both the directness and the subtle humor of "Web::Mention" the best.

From the repository's own README:

The Web::Microformats2 modules provide Perl programs with a way to parse and analyze HTML documents containing Microformats2 metadata. They can pull Microformats2 information from a given HTML document, representing it as a queryable in-memory object. They can also serialize this object as JSON (using the Microformats2 rules for this), or read an already JSON-serialized Microformats2 structure for further analysis.

Why a new module, when CPAN already has three Microformats modules?

CPAN already has HTML::Microformats, Text::Microformat, and Data::Microformat. However, putting aside the fact that the most recent of these was last updated five years ago, they all deal with the original iteration of the Microformats standard. The module I propose, Web::Microformats2, specifically and exclusively addresses Microformats2, a wholly new specification.

Microformats2 is related to its similarly named predecessor in general intent, but its design philosophy and implementation are quite different. As such, software that parses Microformats2 metadata will necessarily be completely separate from that which parses Microformats(1).

Yes, this is a little confusing. I wish it were less so. But that's why my proposed name for this module is "Microformats2": it's simply and literally what the underlying standard calls itself, for good or ill.

Why "Web" when it deals primarily with HTML and JSON input/output?

My motivation for creating these modules is the IndieWeb movement, which uses Microformats2 as a common standard throughout its many proposals and specifications. I wish to implement certain IndieWeb standards in Perl, and that requires Perl's ability to parse Microformats2 metadata, both as found in HTML documents and as pre-processed JSON.

By filing this modules under the "Web" top-level namespace, I hope to signal their usefulness to the ideal of the open web, specially that as espoused by the IndieWeb movement. In this sense, the specific technologies involved (including HTML and JSON) are less important than the philosophies that hope to bring about a more open web, overall.

And, yes, more practically: were I to name this "HTML::Microformats2", I'm afraid that would imply it to be version 2 of Toby Inkster's HTML::Microformats, which it is not. It serves a wholly distinct purpose from those older modules, and I think it ought to have an appropriately distinct name within the CPAN.

This module is a pure Perl implementation of the methods that are currently part of the Zcash Payment API client calls (zcash-cli). The method names and parameters are identical between the Zcash Payment API reference and this module. This is done for consistency so that a developer only has to reference one manual: https://github.com/zcash/zcash/blob/master/doc/payment-api.md

Zcash is based on Bitcoin. Zcash supports all commands in the Bitcoin Core API (as of version 0.11.2). This module is a fork of the Bitcoin JSON-RPC client (Bitcoin::RPC::Client) from Wesley Hinds.

Implement an easy-to-use command line interpreter based on Term::ReadLine and Term::ReadLine::Gnu.

First-time users may want to read the documentation for Term::CLI::Tutorial and Term::CLI::Intro first, and peruse the example scripts in the source distribution's examples and tutorial directories.

This is the name I finally came up with following alot of test and prototype code and the comments from this http://prepan.org/module/nYgPE9VY5gi

I check about on Cpan the name space is free

Database::Accessor

and is is sort where I want it to be

This simplifies GUI development using a textual representation of a interface written in a text editor (monospace font required) as a string and parsed to create an interface without needing to know much about the underlying toolkit (current focus of development is Wx, but will include (HTML, Tk and ncurses)

I have never submitted a module before but I think this could be useful to other people as I did a search on cpanm for something that would easily pass a hash back of command line arguments and validate them (Validation is optional). Future plans include custom die messages and aliases for aguments. Let me know what you guys think if this would be useful, If you see anything that wouldnt work, possibly some advice on namespace etc. Thanks

--Validation The Module can validate on 7 Different constraints REGEXP - {'REGEXP=>'^[-+]?[0-9]'} - Specify a regex the passed data must comply with. MINMAX - {'MINMAX'=>{min=>20,max=>40}} - Specify minimum and maximum numbers the argument must be. GREATER_THAN - {'GREATER_THAN'=>{min=>20}} - Specify a minimum number the argument must be. LESS_THAN - {'LESS_THAN'=>{max=>40}} - Specify a maximum number the argument must be lower than. ASCII - ['ASCII'] - The argument must be any ASCII text with spaces allowed. NOSPACES - ['NOSPACES'] - The argument must have no spaces. INT - ['INT'] - The argument must be a number. ANY - ['ANY'] - The argument must be defined.

You can validate each argument on as many types of validation as you want by stringing together each array ref or hash. The Argument must pass each constraint

--Example 1 - Validating with a inline object. $Args->validate( '-a'=>[ 'ASCII','NOSPACES',{ 'MINMAX'=>{min=>20,max=>40} } ] );

--Example 2 - Validating with a hash spec. my %spec = ( '-a'=>[ 'ASCII','NOSPACES', {'MINMAX'=>{min=>20,max=>40} } ] ); $Args->validate(%spec);

The module will display error messages and die on failed validation by default. If you dont want this you can pass... $Args->validate( no_errors=>'1','-a'=>[ 'ASCII','NOSPACES',{ 'MINMAX'=>{min=>20,max=>40} } ] );

= ROADMAP =

• first oop, then overload

• allow non binary states (dispatch internally)

= Description =

This Modul should help to manager many states in an complex environment.

You can define callbacks for all states & combinations at one place and later change only the $progress.

I use a very simple approach in an old project and i want to make a easy implementation for a new project.

The events only get fired if a related flag/counter is changed.

I am absolute unsure if there are problems with such a interface (overloading) or should i better use simple function calls ($progress->activate(PROGRESS_FIND);)?

Also the signes for setting & checks flags are my first thought, perhaps i should stick with the default binary operators (but i am most of the time confused with them).

Also i guess i need some modes:

• What if someone registered a event with an exact counter like 10 and later increment this counter by 2 from 9 to 11. Should the event fired or not? (mode => 'singlestep')

  • Otherwise if he use exact counters, he should avoid incrementing by more than 1

• What is someone want to disallow setting states again? Like PROGRESS_FIND is off and he set PROGRESS_FIND again to off? (mode => 'strict')

• ggf. einen speed-mode, der davon ausgeht, das bereit nur bitfields genutzt werden?

This module is designed to print indented texts produced by many modules that could not know about other modules. Once configured the indentation will be common for all modules printing indented texts.

This module is designed to be used in the simplest way as much as possible. It provides some methods to handle with indentation. Also it doesn't require any extra modules.

A rule it's a minimal set of conditions to be met to write an entry to a logfile. You must add valid rules before starting the engine.

Once started, the engine will check events every x seconds (specified using interval argument) and for every registry (System, Application, Security, Installation or a user defined one) that is requested at least in one rule will check for an event's source specified and optionally for some text contained in the event's description.

If the rule it's succesfull then an entry it's wrote in the specified logfile. A custom callback can transofrm the line to be wrote using the format option. The parser can optionally shutdown itself if endtime it is specified.