It's been a few years since I last posted here. I've gone on to a different job and jumped back into Perl after an extended time away. Stuff has happened in that time.
Like Moose.
The use of roles is nice. I can declare an expected interface and easily test that an object or class implements it. I can use that information to know what kind of capabilities I can expose to the world.
I'm working on a framework for building RDF servers. I need such a beast to support some research projects at the university, but decided that I should produce something that might be useful to someone else. Of course, that means it has to be able to do things that I don't need to do.
But I don't want to have to program every conceivable behavior.
Instead, I'm building a framework that lets me get done what I need while staying flexible enough that someone else can replace bits of it to get done what they need.
So far, I have the following as a way to build a server (subject to change, of course):
package My::Server;
use RDF::Server;
with 'MooseX::Daemonize';
with 'MooseX::SimpleConfig';
with 'MooseX::Getopt';
interface 'REST';
protocol 'HTTP';
style 'Atom';
#----------
my $server = My::Server -> new(
handler => [ workspace => {
collections => [
{ # defines an app:collection
path_prefix => 'gallery',
entry_handler => [ RDFCore => { } ],
categories => [ ]
}
]
}]
);
$server -> start; # would run on port 8080 by default
That will bring together everything needed to run a standalone server exposing a REST interface over HTTP using POE. Other protocols could be Apache2 or FastCGI (or even plain CGI if we really wanted to). I'm not sure what other interfaces should be. If I can figure out how, I'll make the triad HTTP/REST/Atom the default.
My::Server->handler is an object that will handle the actual request. The HTTP and REST classes just handle the communication with the world and how the request gets handed off to the handler object. This lets the same data backend work with different protocols and interfaces.
The handlers determine if we're speaking RSS or Atom and how the path (as supplied by the interface class) maps to data. The interface class also determines what action is requested.
The 'style' declaration is optional and mainly determines how the configuration is handled. The Atom style expects a hierarchy based on RFC 5023, though the top-level document type can be any of the ones defined in the app: namespace.
Hopefully, if I can get everything together and tested and working, I'll get something out on CPAN in the next week or two.
