This post originated from an RSS feed registered with Java Buzz by Chris Winters. Original Post: Random OI stuff Feed Title: cwinters.com Feed URL: http://www.cwinters.com/search/registrar.php?domain=jroller.com®istrar=sedopark Feed Description: Chris Winters on Java, programming and technology, usually in that order. Latest Java Buzz Posts Latest Java Buzz Posts by Chris Winters Latest Posts From cwinters.com

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.