-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 =pod The other day, someone emailed me about L. I thought I marked the email as "reply to soon", but I actually deleted it. Oops. Anyway, if you are that person, please get in contact with me again, I'm really sorry for deleting your email. With that in mind, I thought I'd write a little about my plans for the future with respect to Ernst. Basically, the current version is a prototype that I wrote to see what metadescription systems are all about. I liked the concept initially, and now that I've implemented it, I like it even more. The implementation, however, does have some problems. The biggest is that you have to C to use it. This creates a metaclass compatibility pain point -- can a C class subclass an Ernst class? Can Ernst roles be applied to regular classes? (The answer to all of these questions should be yes, but in the current implementation, the answer is no. Attributes in roles can have metadescriptions, but must be regular Cs; everything else has to be a class that says C instead of C. This is dumb.) Anyway, Moose has "metaroles" now, and using that feature will result in a cleaner implementation. The first step for a "real" Ernst will be to fix that problem. A Simple Matter Of Programming :) With a solid implementation of the internals, a new set of problems comes up: B It is a pain to have HTML snippets inline with your class attributes, after all -- but it is also messy to sequester them off somewhere that would require a config file to load properly. The idea is to I attributes and classes, and the class is the best place to do that, but sometimes the descriptions are too verbose. What should we do about this? B As I was implementing the first version, I was tempted to implement my own types. Moose's types were too inflexible at the time, I thought; I wanted types that could be incrementally validated, and that understood that they would both keep my program consistent ("HashRef[Str]") and be used to tell a user that his data was not valid. (A password type would be a String, of course, but it also had other restrictions like "Your password should be at least 8 characters long." and "Your password should contain at least 42 numbers." When generating a UI, you want to present all errors at once and a single Perl code block just isn't enough to do that; we need real introspection.) Anyway, this is another problem that Moose is solving; type constraints have received a lot of love lately, and I think we can do everything we need there. B Right now, it is a class that has an "interpret" method. I think this is too flexible, as it doesn't really abstract anything away. You might as well just call it a function. We need to decide what interpreters should do, and then determine what the common API should look like. (There are interpreters in the Ernst distribution now, but I really wasn't sure what the API would look like when I was writing them. I just made them work.) Basically, if you have thoughts, let's discuss them on C<#moose> (irc.perl.org). Once these issues are worked out, we can write the real implementation! Speaking of the future, my "main project" right now is rewriting L. Angerwhale started out as my first "real" Perl and Catalyst project, and grew to actually have some users. Looking back, I really should have discouraged people from using it -- too many ideas were experimental and turned out to not work in real life. (Do you really like PGP-signing your comments? It seems not; I only know of three people who post here that sign their comments. Everyone else stays anonymous. This leads me to believe that PGP-only authentication is a bad idea.) Anyway, the idea for Angerwhale-ng (or Angerwhale 2, even though there never was an Angerwhale 1), is to not be experimental anymore. I really want to create a I blogging platform, and replace Wordpress and MT throughout the Internet. Those platforms are too hard to extend, are messy internally (and extensions are messier), try too hard to be generic CMSes, and don't even have good support for writing about programming. (Nearly every Wordpress blog I see turns quotation marks inside code snippets into smart-quotes. WTF?) It's time to put a stop to that insanity and do blogging I. So, my high-level goal is to create a platform that is cleanly extensible in ways that I don't foresee. Angerwhale 1 tried to do this (and was pretty successful), but too many things required knowledge of the internals. I am aiming for something more transparent and flexible. Emacs is a great example of this. Nobody ever intended for Emacs to be an IRC client or mail reader. But thanks to the flexibility, those features arose naturally. Someone wanted them, and the tools to build them were already there. So they built them, and now everyone can have them. That is how I want Angerwhale to work. The biggest factor contributing to the extensibility will be L. There will be no database schema; everything will be a Moose object in the database. That means that an extension that wants to hook something can be a role applied to an instance. (Just like you were extending a Moose class in memory.) Users may not have an "openid" field by default, but you can apply a role and then they will. (But actually, this specific case is better handled by delegation. Although I want things to be easy to extend without me providing explicit extension points, I will try to provide as many explicit extension points as possible. The goal is to be easily extensible AND to have very clean internals.) Since there is no database schema to mess around with, flexibility is easy. The app doesn't know or care about your extensions; they Just Work. (KiokuDB also helps in other areas -- performance will be a lot better than my ad-hoc file + attributes system that Angerwhale 1 uses. KiokuDB is U, and scales well too.) (One feature that doesn't fit into my narrative is that Angerwhale will be a blogging platform -- one instance will be able to host many blogs. That means that we can make better use of memory; one blog may take 300M of RAM, but 1000 blogs will only take 305M. This means that Angerwhale will be good for hosting individual blogs like this one, but also good for hosting community sites like L and L. I do intend to provide a public blogging service for Perl bloggers as my first deployment, and hopefully replace C's aging journal system without destroying the excellent community features. You'll also get Planet Perl for free.) The next part of Angerwhale will be a new web framework. It won't be like the other new web frameworks, though; the goal is to unify all the Perl web frameworks and provide a true framework framework for everyone to build on. (The goal of the other "new" web frameworks, it seems, is to provide fewer features under the guise of "simplicity". Forcing users to reinvent the wheel is not simplicity, though, and I think this idea sucks. Perl is about TMTOWTDI, not being told that your way is wrong and that you should go fuck yourself if you don't like I way.) The framework will consist of 4 completely separate parts. The first is the "app engine", to support things that concern the entire application. It knows nothing about the web, and doesn't care. (So you can use it in non-web daemons too.) It will provide features like timed events ("clean my sessions table every hour"), an event loop (so that you can fork, fetch web pages, or access your database I), logging, and debugging tools (you can embed a C instance and introspect your live application). It will be C based, so you can freely choose between C, C, or C in your application. (The other parts of the framework, like C, C, C, and so on, all use AnyEvent, so the framework won't make any event loop policy decisions for you. That way you can use your favorite event loop, or run code that already depends on one, inside the framework. This provides the most flexibility and reusability, and I like the AnyEvent sugar a lot anyway. :) The next part is the HTTP helper, C. This is what actually glues the app to the web. I am currently writing an C backend for C, so that web IO is completely non-blocking. C gives you the basic request/response capabilities, and also provides middleware (debug screens, authentication, etc.). It knows how to talk to mod_perl, or be its own server, or be served with FastCGI; so, as with Catalyst apps, this is something your application doesn't need to worry about. Develop with the embedded server, deploy with FastCGI, it will all work. The idea is that it will handle everything that is specific to the web, but not specific to your application. (If you haven't tried C yet, you should. It's really easy to set up, and is a great fit for applications that don't require a "real" framework, but that you don't want to use CGI for. And let's face it, you don't want to use CGI for anything but the smallest toy apps. My C on CPAN uses it, so take a look.) The third part of the framework is a component loader. Current web frameworks tend to load components "automatically", but this is not always the most desirable approach. Something like C is much better. My framework will let you load components however you want; you can do it Catalyst-style, use can use Bread::Board, or you can just do it with some code. Your choice. At this point, you have a solid foundation for building a long-running Perl application, you have a generic way of interacting with the web (complete with niceties like middleware), and you have a solid way of loading and configuring the application's components. That leads us to the last layer, the actual framework. Basically, you can do what ever you want here. I am planning on making it possible to use existing Catalyst controllers in the application, and to support Continuity. (I have use cases where I want both styles in my app -- Catalyst-style actions for the public part, and Continuity actions in the administrative area.) Stevan Little is currently working on a framework that is document-based; you make objects that know how to be mutated and how to render themselves, and the framework takes care of the rest. This will integrate cleanly with this framework, of course. If you really don't like framework-y stuff, just use C to assign function calls to URIs. It's simple, easy to understand, and you can dive into something more complex later, if you want to. The best of all worlds. So that's basically it -- the future of Perl web frameworks is unification. Users shouldn't have to commit to one way of thinking -- everything should work together. That is my goal. It's important to say that this isn't just pie on the sky -- I am actively working on these projects (and not by myself, this is a community project). I will be talking about this stuff more throughout the year. First at NPW, and at YAPC::NA, YAPC::EU, and YAPC::Asia. Hopefully by YAPC::EU and YAPC::Asia, this will be code you can use in your own applications! Anyway, ping me on irc and let's chat! -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkmukacACgkQ2rw+dVvzZm1tYACfSJ/k7Cb1vGyhaU9aURBc0k8+ Gd0An0Xih/SCjZdRZyI6yefTsu69Dzsh =HCBC -----END PGP SIGNATURE-----