Implement a provider of role-based authorisation.

Create a permission object that goes something like

$permission = $auth->permitted ( permission $user, write => $location ); # permission is optional here
return $permission if $permission->denied or $permission->permitted;

$permission->permit($reason); # stores the caller package and line just in case
$permission->deny($reason);

It would be good to remove the /environments/, /public/, and /views/ folders from the dist as they ae misleading (neither forms part of Articulate's "core offering" and they make it look like an app not a set of plugins).

However, currently, removing them would break the tests. Some hackery in Articulate;:TestEnv is probably needed.

Write a storage class which interfaces with a KVP store like Redis

There should be a function which provides sorting of slugs

Your distribution (PERRETTDL/Articulate-0.005.tar.gz) contains files MYMETA.yml and/or MYMETA.json. These files should not be included into distribution - they are generated when installing.
See http://weblog.bulknews.net/post/44251476706/stop-shipping-mymeta-to-cpan

P.S. If this report is about old version, please delete old indexed versions mentioned here: http://cpanold.chorny.net/?a=PERRETTDL and contact me.

Create a route package for "Log In" and "Log Out" actions, and a service package for them.

In Articulate::Storage::Local,

• Create should set or die if impossible or already there.
• Set should die if not already there
• get should die if not there.

Dancer Plugins have changed a lot in Dancer2. Dancer::Plugin is not really providing much benefit as far as I can see and getting plugins to work for both seems unnecessary.

• register could equally be a simple sub with exporter.
• plugin_args could be provided by directly passing in args to a constructor.

The only constructor that's really useful is the Articulate one at the beginning, and we could just create Dancer::Plugin::Articulate and Dancer2::Plugin::Articulate.

Split off the following into separate distributions so they can have separate dependencies:

Dancer1:

• Dancer::Plugin::Articulate
• Articulate::FrameworkAdaper::Dancer1

Dancer2:

• Dancer2::Plugin::Articulate
• Articulate::FrameworkAdaper::Dancer2

A provider is always the target of delegation, but not so a Component.

According to http://perldoc.perl.org/5.14.0/perl5140delta.html s///r was introduced in 5.14.0 so needs replacing if 5.10 is to be supported.

Ideally we wouldn't have global singletons but per-app singletons (maybe not even that, but selections?)

Find a way of removing the single use of MooX::Singleton from Articulate.pm which doesn't break the framework plugins/adapters.

Tests on Win32 failed:

• http://www.cpantesters.org/cpan/report/c4bc10a0-6bfe-1014-8e9d-369f0b0bf8b3
• http://www.cpantesters.org/cpan/report/382bfb31-6bfe-1014-ad60-2b9967be6cac

Failed with:

Error:  Invalid default 'An unknown error has occurred' for Articulate::Error->simple_message - not a coderef or code-convertible object at C:/strawberry5162/perl/site/lib/Method/Generate/Accessor.pm line 57.

I have a crafty but possibly bizarre idea for locking...

The problem is you don't want something like:

a->get_meta
b->get_meta
b->set_meta
a->set_meta # conflict!

When any getter is called on Storage, a lock is created, and tied to the articulate request. When the latter is destroyed (or $self->release_locks) then the lock is removed.
While the lock exists, only that request can interact with that resource.
The lock needs to be visible to other threads? processes interacting with the same store.

Create a syntax class which provides helpers (like constructors for item, request, location) so classes don't have to be loaded individually.

When an item is retrieved, there should be an option to pass the data into a different constructor (like User instead of item) so that it has semantic methods.

For example, Articulate::Construction which delegates to constuction classes which determine, probably based on the location, what the class should be.

It would be good if single-key hashrefs could be instantiated as class+args, so all these mean the same:

- Articulate::Class
- Articulate::Class: {}
- class: Articulate::Class
  args: {}

Articulate::Validation should operate on Articulate::Item objects, not on separate meta/content

Looks like this slipped through the rewrites that followed the creation of the Item class.

Come up with and roll out an instantiator which turns class names in things like augmentation into objects, in a way which can be reused across all the delegator classes.

It would be very useful to have an object which is configured as a sort of 'sitemap' of locations to provide the sort of functions that are currently hard-coded (somewhat esoterically) into Storage::Common.

Useful methods might be:

• is this a valid location?
• what are the last endpoints we have to provide (i.e. models)
• what are the which can
• show me all the endpoints!

It needs to be possible for components to add to the endpoints before Storage::Common compiles things into a regexp or have Storage::Common ask for the regexp each time?

There doesn't seem to be a reason for interpreter to be separate from augmentation. Make it a type of augmentation.

There should be a facility for indexing content, delegated by Articulate::Indexation which is notified by the storage component on all write events (set and delete).

Pick one of

• spaces
• tabs

And consistently use it throughout the code.

Create a simple working example of localisation.

Determine whether it is a good idea to design a generic interface to searching indexes. Answer the following questions:

• Is there some generic form a query will take?
• Is this a method of the Indexation component?
• Is there a separate Searching component?
• Can you search without indexes?

Create service providers and route packages for managing users and permissions.

Instead of singletons for things like augmentation, work out how (and if it's a good idea) to implement lazy-loaded classes like Dancer::Plugin::DBIC does.

In order to reduce the number of DB calls, write an interface to caching that allows you to cache items by location:

• Immediately after retrieval from the DB
• Optionally, when they have been augmented

The test suite fails for perl >= 5.20 and <= 5.12.
See http://matrix.cpantesters.org/?dist=Articulate

With access to Articulate::Navigation it should hopefully be possible to create routes based on the data model... i.e. a turnkey solution for APIs in which you need to touch nothing but config.yml.

There should be a facility for grouping content suitable for the following use cases:

• Ordered alphabetically by slug (e.g. for a collection of articles where no particular order is required, or for a glossary)
• Ordered manually (e.g. for a reading list or tutorial where the order has pedagogical value)
• Ordered by date (e.g. for a blog or similar)

It should be possible for a user to add items to any of these groups, and, in the case of the manually-ordered option, to sort them.

Sort order should be performed by dispatch to a sortation class.

Create a layer which combines Articulate::Service with Articulate::Serialiser and accepts a list of route classes.

There should be a way of creating an item in which the creator does not wish to deal with conflicts - i.e. Storage will always create the item and will potentially return an item with a different location.

Challenges:

• vulnerability to race conditions
• slow
• how do you deal with items missing in series - given item-1, item-3, do you create item-2 or item-4.

Services should register verbs to make it easier for users to ask "what can I do with this content?".

It's probably not a great idea to slurp it in and perform string ops on it, is it?
Do a POC to demonstrate that you can upload and serve images.

When data goes in there should be an opportunity to enrich/coerce it before putting it into the database. Create a Coercion class comparable to the Augmentation class.

Write a storage class which interfaces with DBIC

CRUD would be a lot more flexible if it did not assume the return type was article.

Create a class which connects to the framework and provides things like get, post, session for Dancer1/2/etc.