ArangoDB ArangoDB 2.x HTTP API interface
ArangoDB implements the ArangoDB 2.x HTTP API interface (mostly) and uses Furl HTTP client as it's faster than LWP. My plan is to continue this, so it will at the end implement full HTTP API.
Now, I have a problem about namespace as there is already two other ArangoDB API. One named ArangoDB (implements 1.01 API) and another one ArangoDB2 (implements 2.x API).
Reason why I created new one, was that documentation of ArangoDB2 module in that time was quite poor and I didn't have time to figure out how to use it. So, I created new one more faster.
So what should I do with my version? How to name it or not release it all?
YAML::Tiny::Literate Provide "literate" update for YAML files.
Provide and "extension" to the excellent YAML::Tiny module that allows writing back modifications to values that will preserve the structure and comments (if any) of the original YAML file.
This module is intended to be used to support "configuration files" that need to be maintained by both humans and applications. Sometimes adding comments to YAML files can be useful when those files are maintained by humans. There might also be a need for those same files to be updated by an application. In the latter case, changing the structural order and removing comments is disorienting for the humans.
App::Krypte Krypté - A database encryption service w/ multiple user support.
Krypté is a service that provides a simple API to developers so they don't have to worry about how they encrypt their data. Instead they send it off to Krypté and it's taken care of.
Krypté's method of encrypting data and managing multiple users looks like this:
- One random master key ( or
share_key) is created.
- A random user key is created and used to encrypt the master key.
- The user key is encrypted with a password for that user.
- The encrypted user key and master key are stored for that user in the database.
Storing ( Putting ) Data
- Krypté receives credentials and a chunk of data.
- The credentials are validated.
- The shared key is retrieved.
- If the credentials are a username and password, the encrypted user key stored for the username is unencrypted using the password.
- The user key is then used to unencrypt the shared key.
- The shared key is used to encrypt the data using Crypt::CBC with the Blowfish cipher.
- The encrypted result is stored with a sha1 key of the data.
- The key is returned to the initial requester as a key for the data.
Games::JackThief Games::JackThief is a Card Game - It finds out the looser with jack
This game is played with 51 * (Decks-1) cards. The jokers have no role here and out of 4 jacks, one jack is removed which can be of any suit. This game is usually played by 2 players or more. After the shuffle, it would be very tedious for the dealer to give one card to each and every player since the entire cards have to be distributed amongst all the players equally or nearly equally. After both the players get their respective bunch of cards, the process of separation begins. All paired cards are discarded. For example, if the player 1 has two aces, two Kings, two 10s, two 5s, then he will remove these cards. Similarly for cards such as four 7s, four 4s and so on, because these form two pairs. This would go on till the all the cards are not discarded except one jack and the player who will be having the Jack in the end would be called as JackThief.
Hypothesis::API A wrapper for the nascent hypothes.is web API
Hypothes.is is an open platform for publicly or collaboratively annotating documents on the web.
This Perl module allows convenient access to some of the public HTTP API for Hypothes.is: https://h.readthedocs.org/en/latest/api.html
I've already uploaded it to CPAN - found out about PrePAN mid process. Still, as I'm a bit new to the experience I would welcome a review.
Parse-File-Taxonomy Validate a CSV file as a taxonomy
This module takes as input a plain-text file, verifies that it can be used as a taxonomy, then creates a Perl data structure representing that taxonomy.
Taxonomy: definition For the purpose of this module, a taxonomy is defined as a tree-like data structure with a root node, zero or more branch (child) nodes, and one or more leaf nodes. The root node and each branch node must have at least one child node, but leaf nodes have no child nodes. The number of branches between a leaf node and the root node is variable.
CalDAV::Simple high-level module for doing a subset of CalDAV things
I'm working on a simple module that will provide access to a subset of CalDAV features with a high-level interface. Initially it will just provide access to todo items.
There is an existing Cal::DAV module, but it doesn't do what I want, has dependencies I don't want, and I'm planning a almost completely different interface.
I'm not sure what namespace to use:
- it's an application level protocol built on top of HTTP, so I think Net:: and HTTP:: are out.
- I don't plan to provide full CalDAV, so HTTP::DAV::CalDAV doesn't feel right
- I plan to use Moo, and return objects, so CalDAV::Tiny is ruled out (I'm not Toby!), though my general approach (simple interface to a subset of functionality) does match the Tiny philosophy to some extent
- I don't plan (at the moment anyway :-) to do all of CalDAV, so just 'CalDAV' isn't appropriate
So while I don't really like ::Simple module names, I can't think of anything better right now. Any suggestions?
BitPay::key_utils Provides required cryptographic functions to use the BitPay 2.0 API.
This library provides utilities for use with the BitPay API. It enables creating keys, retrieving public keys, creating the SIN that is used in retrieving tokens from BitPay, and signing payloads for the X-Signature header in a BitPay API request.