I was happy to see a bunch of posts by someone other than me on the OI wiki. Hooray Joe! John also had some encouraging words about the OI2 beta release. (I like the verb “spelunking” for figuring out how the hell everything is tied together in a new app.)
I jotted down a bunch of OI todo notes while at YAPC. Here's a few:
- While talking to gav I realized most people on use.perl probably wouldn't mind me cross-posting blog entries from here, even if they're not about Perl. Building this functionality into the OI 1.x news package is a little more work, but building it into OI 2.x should be a snap since all actions are observable. This will provide an excellent incentive for me to move my own site to OI 2.x (as it stabilizes) and give a good example of what you can do with observable actions.
- Add Log::Log4perl support instead of homegrown. Increases dependencies but gains LOTS of functionality. (See Eric's talk for intro.)
- Docs to write: tutorial for creating a package (already has a placeholder in OI2::Manual::Tutorial), what is a datasource, creating an adapter (create one for email?), cookbook! (thanks Ingy), creating a content generator.
- Test content generator for Text::Template
- Create content generator for HTML::Template
- Figure out how (if?) to decouple controller from initial action
- See if using CGI::Kwiki is possible in OI:
OI --> Kwiki --> content --> OI --> user
So you could embedd OI-isms in the kwiki output or translate kwiki-isms into OI-isms
- Creating a threaded OI2 server wouldn't be that difficult as long as we create the CTX first -- it's (more or less) read-only and individual threads would get a socket or higher level construct (like from HTTP::Daemon) and simply create their own request/response/controller. The only problem is that we do ask the CTX for the current request/response...
I think the next beta release will consist almost exclusively of doc updates. Docs are generally a user's first impression of a module and if they find what they're looking for quickly it's that much more incentive for them to download and play. Generally "what they're looking for" consists of: "What does this do?" and "How can I customize it?" Providing easily found answers to these questions is key.
Of course, the second set of impressions comes from getting the app running quickly, but I think the intro doc takes care of this pretty well.