2007.03.27 Roundtable Summary

[Michael Milner]

Here's a summary of the developers meeting held on IRC yesterday.  The main purpose was to lay out a plan of action for Ruport 1.0.  Please feel free to give your opinions on any of the topics.

Mike

----------------------------

= Ruby Reports 1.0 Roadmap Planning : 2007.03.27 =

== Participants ==

- Gregory Brown <sandal>
- Michael Milner <mikem836>
- Aredridel <Aria>
- James Edward Gray II <JEG2>
- Anthony Eden <aeden>
- Eustaquio Rangel de Oliveira Jr. <TaQ>
+ several lurkers

== Transcript ==

If you missed it yesterday or want to refer to it, you can find the transcript at:
http://rubyreports.org/transcripts/dev-discussion-1.0.2007.03.27.txt

Which is also linked to from our ChatLogs section of the wiki (for bookmarking)
http://stonecode.svnrepository.com/ruport/trac.cgi/wiki/ChatLogs

There are also some in-meeting notes on the wiki at:
http://stonecode.svnrepository.com/ruport/trac.cgi/wiki/OhOneOneMeeting

== Summary in three lines ==

21:25 <@sandal> okay JEG2.
21:25 <@sandal> you've got a class called CrackRock
21:25 <@sandal> and it's got a method_missing hack in it

== Introduction ==

We began by looking at the existing roadmap and noting that it currently shows standardization of the API and performance improvements as the two major remaining goals for 1.0.  In this context, it was noted that we should develop a benchmark suite - this was discussed in more detail later.  A question was also posed regarding the availability of comprehensive documentation.  People were encouraged to look at the documentation (tutorials and recipes) currently on the wiki site, but reminded that we do have an effort underway to produce much more comprehensive documentation.

== Stealing Ideas ==

<TaQ> reminds us to not lose emails, and suggests we take a look at his PHP reporting package
            http://phpreports.sourceforge.net/

== Acts As Reportable ==

The first topic of discussion was the fate of acts_as_reportable.  We announced recently that we're planning to move the data collection parts of AAR back into Ruport core.  While there wasn't any particular objections to this idea, there was a feeling that it would benefit the Rails community to maintain a plugin as well.  Initially the plugin would just be super lightweight in that its only function would be to require the necessary parts of Ruport core.  Later, we could develop the plugin along the lines of supplying Rails views and helpers.  However, we need to rename either the AAR stuff that migrates to core or the plugin since we don't want confusion between the two.

It was noted that there is an AAR branch for the experimental work on Rails views and that it would be updated in the next day or two with a new approach, so anyone who could check it out and provide feedback would be appreciated.

== gem_plugin ==

Although Ruport no longer auto-requires gem-plugin, it is still a dependency, so a possibility is to make it optional.

== Ruport 0.9 ==

The goal for the 0.9.3 is to do some cleanup and documentation.  It was noted that there have been >200 changesets since 0.8, so development has proceeded very rapidly.  Because of this some of the code is ugly and API documentation is lacking.  So the goal is some code refactoring, cleanup, and addition of documentation.

== Documentation ==

On the subject of documentation, it was requested that we fix the tutorials, etc. on the wiki site to be sure they're up to date.  The problem is that our stable release is still 0.8, and 0.9 has been a development release.  For that reason, we don't plan to produce any additional documentation for 0.8, but will definitely accept and fix bug reports against 0.8.  Any bug reports for documentation can be filed against the Ruby Reports Documentation Effort milestone on the Trac site.

We could also set up a site to access the 0.9 API documentation if that would help people.
It would likely reside at http://api.rubyreports.org/edge

== Formatting System ==

In addition to the ugliness of the code in the formatting system, which needs to be cleaned up, we are lacking multilevel grouping support for most of the built-in formatters.  Both Greg and I would rather not support it because it adds a lot of complexity to the built-in stuff, which is really intended as a base for people to write their own formatters.  The group was asked if anyone had any thoughts on this, but nobody seemed to have any specific opinions on whether or not we should support it.

On the topic of using our built-in stuff as the basis for custom formatters, it was noted that we need to add more helper methods to support this approach.  The pdf formatter currently does this pretty well, but the others do not.

Another question was if people like the 0.8 style options for formatting, where layout options were separate from other options, or if they like the 0.9 style, which are a single type of option.  The general consensus was that 0.9 style is preferred.

That led to a discussion on some refactoring of the rendering methods.  We think it would be a good idea to refactor out the as() and renders_with() methods into a module that people could mix in to their own data structures.  Internally, at least, it would eliminate some duplication within the existing data structures.  The question arose as to whether we should support the to_* hack.  We want to be sure not to cause problems for people using the module by breaking existing method_missing() code.  JEG2 offered a suggestion on how to get around this, so it will be attempted.

== Error Handling ==

Currently, our error handling consists mostly of falling back on standard Ruby errors.  The question was raised if we should create a custom set of errors, and this suggestion was considered a good idea.  The errors should descend as a single hierarchy from RuntimeError.  We also discovered an example where Ruport gives back an unintelligible error (when calling as() with an undefined format), so we need to fix this as well as find anywhere else that we might have a similar situation.

== Performance ==

The idea of a benchmarking suite was then discussed in more detail.  The idea would be to give people a small script to run the suite and use Ruport to format the outputted statistics into text and html.  This will let us track progress when refactoring as well as identify bottlenecks.

== ruport_utils ==

We're planning to bundle some functionality into a ruport_utils package (invoice, graphs, report_manager, etc.).  To use it you'd be able to require the whole package with require 'ruport_utils' or only parts with require 'ruport_utils/graph', for instance.  We'd also add a rake task to rope that would help you add these.

== Further discussion ==

You're welcome to discuss these topics in general here.  If you'd like to go into some deep discussions about the specifics of something you've seen here, you're welcome to come join us on our development list:

http://groups.google.com/group/ruport-dev

We will be using this to discuss and work our way through design decisions, so potential contributors may find the discussions there helpful.

== Roadmap Update ==

We'll be updating the Ruport Roadmap on the wiki, and updating it with the latest path to 1.0.   We ask that folks get as much feedback as they can to us before April 1st, as we'd like to start putting these plans into action. :)