WebService::CDNetworks::Purge A client for the CDNetworks's Cache Flush Open API v2.4.0
I want to create a client for the CDNetworks's Cache Flush Open API v2.4.0 service. These are the namespaces that I considered: * WebService::CDNetworks::Purge (I think the most appropriate) * WWW::CDNetworks::Purge * NET::CDNetworks::Purge
Net::Object::Peer "Network" with pub/sub + direct peer-to-peer messaging
Net::Object::Peer is a Moo Role which implements a publish/subscribe peer-to-peer messaging system, based upon Beam::Emitter. Objects in the network may broadcast events to all subscribers or may send events to a particular subscriber.
Subscriptions and unsubscriptions are tracked and messages will be sent to affected objects upon request.
While Net::Object::Peer is designed around the concept of nodes being objects with methods as event handlers, it retains Beam::Emitter's ability to register code references as well.
Net::Object::Peer::Cookbook provides some recipes.
I'm not terribly enamored of the module name; suggestions for alternatives would be welcome!
API Manager Scaffolding for user-defined API's.
I'm working on a module that will allow a developer to write "Classes" in Perl. Then, the developer will be able to call methods in those classes from either the command line, cgi, web sockets, stand-alone web servicer, or from native Perl. The classes will be self documenting and will benefit from parameter type-checking. My module will allow the developer to specify both the input and output data format, such as text, csv, html, json, xml, Perl hash, etc. Finally, configuration/authentication information can be segregated from the main code and perhaps even stored outside of the normal web-space.
So, you would be able to create an Object Class Module and be able to call those methods from the command line during testing. Then you could deploy the same code via cgi for your web applications. At scale, this same code would be available via a stand-alone server.
During testing, you could supply the data via xml and get the results in json, if you wanted.
Geo::Converter::LV03 Convert Swiss LV03 coordinates to WSG84 and and vice versa.
I'd like to know if the package name Geo::Converter::LV03 is possible for a package that exposes to methods to convert coordinats from WGS84 to the Swiss LV03 coordinate system and vice versa.
Alchemy::DataNews Query Watson's Alchemy News API with Perl syntax
Perl wrapper for Watson's Alchemy Data News API: https://www.ibm.com/watson/developercloud/alchemy-data-news.html
The Alchemy Data News API is a very powerful REST API capable of searching news and blog posts for keywords across specified time frames. The API also enriches the articles with various natural language processing techniques that allow the user to perform highly targeted searches.
This module interprets Perl syntax into the REST parameters the API expects.
Sub::QuoteX::Utils Sugar for Sub::Quote
Sub::QuoteX::Utils provides a simplified interface to the process of combining Sub::Quote compatible code references with new code.
Sub::Quote provides a number of routines to make code more performant by inlining separate chunks of code into a single compiled subroutine.
When a chunk of code is compiled into a subroutine by
keeps track of the code and any captured variables used to construct
that subroutine, so that new code can be added to the original code
and the results compiled into a new subroutine.
Sub::QuoteX::Utils makes that latter process a little easier.
MojoX::Log::Any Use the current Log::Any adapter from Mojolicious
MojoX::Log::Any makes it easy to use a
Log::Any::Adapter from within
Mojolicious without getting in the way of the user.
When imported from within a Mojolicious application (of from within a
package into which Mojolicious'
app function has been exported), it sets
log attribute to a
Log::Any::Proxy connected to
whatever adapter is currently available.
When imported, the logger defaults to using
which seems to be the currently maintained adapter for
parameters passed to the module's
import function are passed as is to the
get_logger function from
Log::Any, to allow for user customisation and to
maintain a coherent interface with that package.
There are numerous packages in the
MojoX::Log namespace providing an
interface with the various different logging mechanisms on CPAN; except
There is also a
Log::Any adapter for
Mojo::Log, which makes it possible
to use that logger from any application using
Log::Any; but not Mojolicious apps.
This package attempts to fill that void by offering Mojolicious applications an easy
way to plug into the current
Log::Any::Adapter (whatever it may be).