Forum: Nitro I, Nitro

I am super happy to announce that thanks to George I am now a
_professional (as in cold hard cash, baby)_ Nitro developer! From now
on I will be heading up Nitro development along with George. My goal
is to push Nitro into a high quality 1.0 release as quickly as
possible. My priorities are:

(1) Uber User Friendly.

Basically I want to do something like:

     $ gem install nitro
     $ ntiro demo helloworld

and

     $ gem install nitro
     $ nitro create ~/mynitroprojects/foofish
     $ nitro start ~/mynitroprojects/foofish

Without one single hickup.

(2) "Like-Butter" Development

I would like to get a central repo up. And create some firm standards
for branching and tagging.
Also, I want to improve the development toolset to make standard tasks
very simple, get the repo in such nice-and-neat order it's freaky, and
eventually have some automated tools that keep us all well informed on
a regular basis.

(3) Doc Wizard

I want to find someone who's willing to contribute considerable effort
to working on Nitro docs once we get passed the 0.50 release. I will
help on this of course, but it would be best to find someone who can
focus almost exclusively on this aspect of Nitro --this includes PR.
We're looking at the Oxy, API Wiki, RDocs, the Website(s) and
hopefully in the end the first published book. (Did you catch that, a
BOOK! My job isn't complete until there's a BOOK.)

(4) Ruby 1.9/JRuby support

Around the end of the year I will start focusing on getting Nitro
running smoothly on Ruby 1.9 and JRuby, we will also have a try at
other VMs. YARV, Rubinius, IronRuby, etc.

(5) Support George

George is always pushing forward, so I'm going to bridge the gap
between him and a stable Nitro framework. While I also help him with
his more pressing needs, such as a new formhelper, admin part, etc.

As always, please provide all and any suggestions you have to offer,
and if you have time to put in some elbow greese, please let me know,
and I will hook you up.

In closing let me say, A VERY BIG THANKS TO GEORGE who has made this
opportunity possible!

T.

I want to help with number 3.  I should have more time post Dec 1st.

Chris

>
> I am super happy to announce that thanks to George I am now a
> ...
> In closing let me say, A VERY BIG THANKS TO GEORGE who has made this
> opportunity possible!
>


Let me just add that *I am thrilled* to have Tom more active in this
project.
I really hope that community/organization relation things will be 
improved
now.

Hopefully, more people on this list how would like to use Nitro/Og for
commercial purposes
would think about supporting some nitro hackers with free time and the 
will
(and capability) to work on improving
the platform.



regards,
George.

On 11/2/07, Trans <transfire@gmail.com> wrote:
> I am super happy to announce that thanks to George I am now a
> _professional (as in cold hard cash, baby)_ Nitro developer! From now
> on I will be heading up Nitro development along with George. My goal
> is to push Nitro into a high quality 1.0 release as quickly as
> possible. My priorities are:

Great news.
All of the following plans sound great too.
One question:  About the plans re: Og?
There was mention that disentangling it from Nitro would encourage
people to use it in other contexts. Vote +1
I can confirm I've just had an exchange where the barrier was:
"From what I understood Og and Nitro are pretty much inseparable."

Cheers
Mark

On Nov 1, 6:30 pm, "Mark Van De Vyver" <mvy...@gmail.com> wrote:
> One question:  About the plans re: Og?
> There was mention that disentangling it from Nitro would encourage
> people to use it in other contexts. Vote +1
> I can confirm I've just had an exchange where the barrier was:
> "From what I understood Og and Nitro are pretty much inseparable."

And we will make that very clear in coming weeks/months. Hell, lets be
clear now ;) Nitro, is a whole web-framework stack that includes/uses
Og. Og does not include/use Nitro. Og can just as easily be used by
any other application independent of Nitro.

T.

> And we will make that very clear in coming weeks/months. Hell, lets be
> clear now ;) Nitro, is a whole web-framework stack that includes/uses
> Og. Og does not include/use Nitro. Og can just as easily be used by
> any other application independent of Nitro.

:))

Trans wrote:
>      $ nitro create ~/mynitroprojects/foofish
>      $ nitro start ~/mynitroprojects/foofish
>
> Without one single hickup.
>   

The hiccup that makes me embarrassed to ask friends to try Nitro is that
request[] doesn't work in  OgAdminController#save.    The scaffold makes
learning Nitro/Og a piece of cake -- instant usefulness before getting
into hand-coding form.

Unfortunately:

ERROR: Error while handling OgAdminController#save()
ERROR: undefined method `[]' for nil:NilClass

/Users/rmela/nitro/repo.nitroproject.org/script/lib/../../raw/lib/raw/context/request.rb:304:in
`[]'

/Users/rmela/nitro/repo.nitroproject.org/script/lib/../../nitro/lib/nitro/part/admin/og/controller.rb:93:in
`save'

Oddly enough, request[] works everywhere else.    Maybe that will by my
puzzle for the week.

Problem found.   The correct fix for OgAdminController#save is not in
OgAdminController.  It's in Cgi#parse_params

Before a fix can be implemented there should be a decision as to whether
post and get params should be hash or dictionary.

Plain old POST request bodies are parsed using Cgi#parse_query_string (
sic ) and that returns a Dictonary:

  context.post_params = parse_query_string(data)

Multipart form data is parsed using Cgi#parse_multipart, which returns a
Hash

    context.post_params = parse_multipart(context, boundary)

... and which also conveniently contains the comment

  #--
  # TODO: RECODE THIS CRAP!
  #++

If a decision is reached that Dictionary is to be used for form data
then the following initializations in Context#initialize would need to
be changed:

    @post_params = {}
    @get_params = {}

So, having no shame, I'll ask a stupid question:  Why Dictionary for
request params?   Also, does using Dictionary for some collection (
post/get params ) and Hash for others ( headers) risk being
counterintuitive?  I think it's reasonable to think of headers and
params as collections, and for a programmer to expect them to expose the
same syntax.

On Nov 1, 10:52 pm, Robert Mela <r...@robmela.com> wrote:
>
>
> counterintuitive?  I think it's reasonable to think of headers and
> params as collections, and for a programmer to expect them to expose the
> same syntax.

Is there a reason for these to maintain order?

T.

>
> The hiccup that makes me embarrassed to ask friends to try Nitro is that
>

I will fix this.

-g.

Yeap,

I think it is needed for making this work:

def my_action(param1, param2)
end

I am not sure though...

-g.

A very big congratulations to you for this certainly unique opportunity!

And also a big thank you to George for all the past effort and for
making this happen!

I would hereby like to announce my candidacy for the position of Nitro
Doc Wizard.

Regards,
(ab)


Trans schreef:
>      $ gem install nitro
> (2) "Like-Butter" Development
> I want to find someone who's willing to contribute considerable effort
> running smoothly on Ruby 1.9 and JRuby, we will also have a try at
> and I will hook you up.
>
>   


--
Arne Brasseur
http://www.arnebrasseur.net
http://www.zhongwiki.com
http://www.bankske.org
arne@arnebrasseur.net

>
> I would hereby like to announce my candidacy for the position of Nitro
> Doc Wizard.
>

Thanks Arne,

as I have already told you when we met, it is possible that I may be 
able to
(financially) support more Nitro hackers in the near future.
but I would like to see some contribution first (that was the case with 
Tom)
not just complaints.
hopefully, more people on this list could step in and support nitro 
hackers.

regards,
George.

I'm really excited about this. There is already a buzz inside 
ThoughtWorks
about this announcement. It would be great to see a genuine viable
alternative to the rails / active record world.

I see nitro having two significant advantages over rails:

* It is just so easy to use. I really do struggle to get my head around
rails. There is a surprising amount of hidden "tacit" knowledge required 
to
become effective with rails, given that it is supposed to be entirely
convention based. I describe it as the difference between struts and 
webwork
(for anyone from a Java background). Struts was ok, and was the 
framework
that made java a viable web technology, but webwork just feels nicer.
(Ironically, "struts 2" is actually webwork 2 - so they eventually 
worked
that out for themselves).

* I can write a web app that talks to a legacy database. Og gives me a 
full
ORM rather than requiring that I own the database. That opens up a whole
class of web apps that are simply not available to a stack constrained 
to an
active record pattern.

For my money (about $0.02), this would be my priority for getting nitro 
"out
there":

- Documentation, documentation, documentation. It doesn't have to be 
clever
or comprehensive. Just a solid walk-through of creating an application. 
The
answers are mostly there amongst the original videos, the cheat sheets 
and
the tutorials. It just needs shaking down and presenting in a clear and
consistent way. I would choose some "typical" users  and target them.
Initially target an experienced ruby programmer writing their first web 
app
in nitro. Then something like a "nitro for rails developers" track.

- Stability. (Funny enough, less important to me than being able to 
write an
app in the first place.) I don't mind if it has rough edges as long as 
the
core stuff mostly works, and the mailing list is responsive to my 
stupidity.
It's pre-1.0 after all.

Cheers,
Dan

Thanks, Arne.

I can offer about two hours per week -- enough for a small section or to
review & test drive whats been written.

On Fri, 2007-11-02 at 10:33 -0400, Robert Mela wrote:
> I can offer about two hours per week -- enough for a small section or
> to 
> review & test drive whats been written.
> 

i'd be willing to review and test drive also.

The Og/Legacy DB question offers a good use-case scenario for the
documentation process.   It was next on my list for cheatsheets, so I'm
already willing to generate *something*.

So the use case is this -- how do I generate that entry such that Arne
can easily integrate it into what he's doing?  Or should I just write a
cheatsheet now, and Arne or whoever can use it as input for their own
version of docs?

One scenario I envision is that Arne is Documentation Tsar.   Generating
documentation himself, but also farming work out to other volunteers.
I'm willing to write submissions as they occur to me, write submissions
as per DocTsar requests, or do legwork and research, legwork, code
reading, and experimentation for things anyone else is thinking about
writing about.

So, let's take Og and Legacy Databases as a use case scenario for a
documentation process and me as an example volunteer.  How might a
process work?

On Nov 2, 2007, at 5:25 AM, Dan North wrote:

> - Documentation, documentation, documentation. It doesn't have to  
> be clever or comprehensive. Just a solid walk-through of creating  
> an application. The answers are mostly there amongst the original  
> videos, the cheat sheets and the tutorials. It just needs shaking  
> down and presenting in a clear and consistent way. I would choose  
> some "typical" users  and target them. Initially target an  
> experienced ruby programmer writing their first web app in nitro.  
> Then something like a "nitro for rails developers" track.

The documentation is the common thread, and the cure is twofold:

- Yeah, write some cool new tutorial documentation. Something a
person could do in a couple of hours that's more than stupid-simple.
- Find all the outdated documentation and encourage everyone who owns
it to update it to current tools/standards

I keep looking at Nitro and Og and saying, "I want to do my next app
using Nitro and Og," but they don't sit still long enough for me to
build up any muscle memory. If a reasonably stable release appeared
and everyone went into "no new features, no api changes, no tool
changes" mode for a month or so, I believe it would help people who
now feel the Nitro/Og ecosystem is a bit slippery right now.

The other common thread is identifying the competition: Is it Rails?
Is it Merb or PLONE? Perhaps a more interesting thing to look at are
these questions:

- What does <insert framework name here> do well?
- What pisses people off about <insert framework name here>?
- Why could Nitro/Og do these things better?

I'll get the ball rolling on this last bit.

- Rails does greenfield apps incredibly well
- Rails pisses off people who use FK constraints in their databases
- Rails has nice generators and rake tasks
- Rails routing pisses off people who have better things to debug
that their routes
- Rails has good hooks for alternative template languages
- It would really piss me off not to have Haml and Sass
- Rails is dirt simple to deploy with Capistrano
- Buying extra memory for my server to run my keen new rails apps
pisses me off
- Rails makes testing a snap (and includes some support in generators
and rake tasks)
- Support of only Test::Unit pisses me off. I use rSpec.

I don't know enough about Merb or PLONE to comment on them, but I'll
betcha there are some things that people will swear are great and
others that expert users get pissed off over each time they bump into
them.

I'm sorry if this seems rambling, but what brought me to Rails was
that there were homegrown tutorials out there that worked. You could
gem install rails and there were no gem version conflicts. You could
rails foo and you got a foo app. You could script/generate scaffold
bar and you got a bar thingie. Migrations only made that better. Og
should be even more capable than that. The point is, everything
worked. And reliably. And in pre 1.0 versions. Nitro/Og's friction
has been the "one thing broken" problem that stands in the way of
going straight through that AHA! tutorial experience.

--s

On Nov 2, 12:07 pm, Robert Mela <r...@robmela.com> wrote:
> documentation himself, but also farming work out to other volunteers.
> I'm willing to write submissions as they occur to me, write submissions
> as per DocTsar requests, or do legwork and research, legwork, code
> reading, and experimentation for things anyone else is thinking about
> writing about.
>
> So, let's take Og and Legacy Databases as a use case scenario for a
> documentation process and me as an example volunteer.  How might a
> process work?

That's a good question.

First let me say though that I am pleased to see so much interest in
this thread, and especially volunteers for writing documentation.
Clearly there remains real interest in Nitro as an alternative to
Rails and other LAMP frameworks.

Before we can really start digging our heals in with docs though, we
need to get 0.50 out. 0.50 will serve as our first weigh station for a
stable API. At that time I will workout a more specific documentation
strategy. In the mean time, it would be useful to discuss the general
ideas of how a good doc process would work. And I think your question
goes directly to the heart of the matter.

I would say the first thing to do is check with community and head
developers to see if such a documentation case is already out there or
in the works. If it is, it may be better to help improve that, rather
then start another. But lets say there isn't and the community
feedback is positive. Then the next thing to do is sketch a tutorial,
be sure to work through it a few times to polish it up, and the post
that to Oxy. Now that may be as far as it goes, which is fine --the
tutorial has contributed to the Nitro knowledgebase. However,
depending on the case, the tutorial might be able to go further and
turn into a section of The Book.

Of course, maybe you don't want to do a tutorial and just want to make
a cheatsheet. Thats cool too. I think maybe adding a cheatsheet
section to Oxy would be a good idea. It would be interesting to see
how much we could turn something like this into an assembly processes.
Could one person create a text-based cheatsheet and another turn that
into a really snazzy graphical cheatsheet, or a screencast?

At the same time, the Doc lead(s) might read this material and use
some information in it to "back-improve" RDocs (which are docs for
programmers) or the API wiki (low-level docs for end users). They
would also be responsible for seeing that information on Oxy stays up-
to-date, well formatted, etc.

Ok. That's just my first rough thoughts, on the matter. Yours?

T.

A B S O L U T E L Y !!

It is good to see firm structure and a sincere push to keep user level
documentation viable.

I love it!!

:-)

Hi gang

Personally speaking

i agree there must be a [START HERE] document like and induction set.

Secondly I prefer a cook book approach to the second level USER
documentation.

BOTH these would be backed by solid PROGRAMMER level documentation.


Cook books and the [START HERE] model can both work on useful use cases.

For example :: I made a web page with html from a book, now I want to 
make a
site based on my ideas -- How do I transfer my existing web to Nitro? 
Some
of the suff oyx does :-)

I trust you find that useful.

A couple of thoughts

On Nov 3, 2007 12:29 PM, Trans <transfire@gmail.com> wrote:
>
>
> On Nov 2, 12:07 pm, Robert Mela <r...@robmela.com> wrote:
> > The Og/Legacy DB question offers a good use-case scenario for the
> > documentation process.   It was next on my list for cheatsheets, so I'm
> > already willing to generate *something*.
> >

<snip>

>
> Before we can really start digging our heals in with docs though, we
> need to get 0.50 out. 0.50 will serve as our first weigh station for a
> stable API. At that time I will workout a more specific documentation

Possibly off topic, maybe of interest, but worth stating explicitly -
I won't have the DBI adapter ready for the 0.50 release.

> that to Oxy. Now that may be as far as it goes, which is fine --the
> tutorial has contributed to the Nitro knowledgebase. However,
> depending on the case, the tutorial might be able to go further and
> turn into a section of The Book.
>
> Of course, maybe you don't want to do a tutorial and just want to make
> a cheatsheet. Thats cool too. I think maybe adding a cheatsheet
> section to Oxy would be a good idea. It would be interesting to see

I think a cheat-sheet should be reasonable prominent, if it is task
oriented. Examples I like are the Sequel cheat sheet on their wiki
http://code.google.com/p/ruby-sequel/wiki/CheatSheet
and
the layout of the flexmock readme (early example and then cheat sheet)
http://onestepback.org/software/flexmock/

IMHO the Sequel style cheat sheet could fill in the place of the flex
mock 'Quick Reference'.
It can be :include: <common_cheatsheet.file>.
This would mean every copy of the Nitro/Og would have a local copy?
I think it is worth some thought/effort to keep the RDoc and 'other'
versions of this section common.

> how much we could turn something like this into an assembly processes.
> Could one person create a text-based

(or one in the RDoc readme?)

> cheatsheet and another turn that
> into a really snazzy graphical cheatsheet, or a screencast?
>
> At the same time, the Doc lead(s) might read this material and use

the cheat sheet directly, and use

> some information in it to "back-improve" RDocs (which are docs for
> programmers) or the API wiki (low-level docs for end users). They
> would also be responsible for seeing that information on Oxy stays up-
> to-date, well formatted, etc.

It'd be great to try and find some way of keeping the docs as common
as possible, but apart from :include: in RDoc I'm not sure what else
can be done.

I'm not very familiar with AR so do not know of a 'well/widely-know'
cheat sheet.  If there is one, mimicking it sturcture (assuming it is
good/reasonable), would be a natural way of indirectly comparing AR to
Og?

HTH
Mark

On Nov 3, 2007 12:40 PM, * William <william.full.moon@gmail.com> wrote:
> Hi gang
>
> Personally speaking
>
> i agree there must be a [START HERE] document like and induction set.

agreed and at the risk of repeating myself ;) I think this
'introduction level information' is best done in the readme file,
which can be duplicated elsewhere, but the readme version should be
the reference point?
More extensive introductory material/howto can be refereed to.

> Secondly I prefer a cook book approach to the second level USER
> documentation.
>
> BOTH these would be backed by solid PROGRAMMER level documentation.

Agreed.  In fact since I always have the pickaxe book and the Ruby
cookbook on my desk I'd say that, for me, the best documentation
(book) would be the Ruby cookbook with the pickaxe appendices.
Is this a longer term target/structure worth setting and aiming for?
It would kill the two birds with one document/book.

HTH
Mark

We need to draw up a list of *what* formats we want to target.

A (START HERE) at the README RDoc level is a great idea.  A README.intro
alongside the current README.og and README.raw.

What are the goals?

 -- install Nitro
 -- verify that it works
 -- proove:  useful common things are really simple in Nitro

If those are the goals, does this achieve them:


Intro I ( README.intro )
 - single-file app ( with Controller and Dispatcher )
 - starting and stopping
- canonical hello world app
   . nitro --create
   . a template
   . a controller
   . an element

Intro II ( Og ) ( README.intro2 )
  - Library example ( Book and Author ), using admin part
   ( or something similarly simple but more exciting )

Intro III (? or maybe this belongs in a tutorial )
   - Add a simple form to Intro II

At this point it's pushing the limits to becoming a tutorial...

What's a "greenfield" app?

Also -- not sure I'd want to enter competition with Rails and risk flame
wars and all.... is it possible to talk about what Nitro does, with
examples, and leave it at that?

Forgot to delete the first spurious sentence -- writing this while
serving part-time as climbing structure for a three year old.

On Nov 3, 2007, at 7:56 AM, Robert Mela wrote:

> What's a "greenfield" app?

 From scratch: http://en.wikipedia.org/wiki/Greenfield_project.

> Also -- not sure I'd want to enter competition with Rails and risk  
> flame wars and all.... is it possible to talk about what Nitro  
> does, with examples, and leave it at that?

Don't get me wrong. I love Rails. It's all I use now. But the risk of
not acknowledging history for new endeavors is that you will repeat
it. No flame wars intended, but there are places where even Rails
doesn't fit well.

One nice "up and running" tutorial for Rails is this:

http://rails.homelinux.org/

It's a bit dated by now, but covered out-of-the-box Rails experience.

Hope this helps.

So is that something in between Tutorial and Book.

   1. Quickstart (README.intro )
   2. Tutorial
   3. "Four Days of Nitro"
   4. The Book

Advantage -- it appears long before "book", and makes a great warmup for
person(s) doing Book.

Somewhere outside the progression but perhaps sharing some resources 
with it

    * Reference ( is this not the same as RDocs? )

Whilst we are on the subject of Og, here's a request that came from 
inside
ThoughtWorks. I'm interested in how it fits into the current model for 
Og:

<quote>
I want unit of work so that I don't have to manually remember to flush 
to
the database or remember arcane rules about persistance through 
reachability
for different collection mappings.

I want Hibernate-style HQL so I can perform complex reporting style 
queries
expressed in my domain language and so that I can map legacy schemas 
without
having to remember ugly table/column names.

I want several levels of caching so that I can be clever about caching 
data
for read-mostly applications. (And anyone telling me ActiveRecord or 
plugins
can already do this does not know what they're talking about.)
</quote>

Thoughts?

How much effort would it be to integrate a Unit-of-Work pattern into Og? 
Or
should I be thinking about a whole other ORM here? As for the HQL-style
queries, I would prefer to see an embedded DSL that supported
database-independent queries, something like LINQ meets HQL. Perhaps 
that's
a separate project that would play nice with Og?

Thanks,
Dan

I'll take a novices stab at this... if only to be corrected/learn 
something ;)

On Nov 5, 2007 9:16 PM, Dan North <tastapod@gmail.com> wrote:
> Whilst we are on the subject of Og, here's a request that came from inside
> ThoughtWorks. I'm interested in how it fits into the current model for Og:
>
> <quote>
> I want unit of work so that I don't have to manually remember to flush to
> the database or remember arcane rules about persistance

I think the persistence unit of work is an object instance - I posted
my first attempt to use Og by hacking someone's AR performance
benchmark code.  I tried to set out all the ways I could find to
'create records'. IIRC, some just took an instance of the object or a
hash and stored it, others you had to klass#save.
Is this what the person above means?

> through reachability
> for different collection mappings.

Huh, sometimes I know I'm dense, and this is one of those times.  It
sounds sophisticated so I'll leave it alone.

> I want Hibernate-style HQL so I can perform complex reporting style queries
> expressed in my domain language and so that I can map legacy schemas without
> having to remember ugly table/column names.

I've never used Hibernate... sounds like the author wants Og to know
their domain language?  Or, do they want to be able to pass blocks to
Og queries?
Og allows legacy tables I've not used them but a mail list/Oxyliquit
search should throw something up.

> I want several levels of caching so that I can be clever about caching data
> for read-mostly applications.

Not as far as I know, but after learning that Caboose::EZ apparently
(who would have quessed) contained some query DSL methods I'm
reluctant to say that something is not in Og ;)
The Sequel project mentions caching, so have a look at that in the mean 
time?

> (And anyone telling me ActiveRecord or plugins
> can already do this does not know what they're talking about.)
> </quote>
>
> Thoughts?
>
> How much effort would it be to integrate a Unit-of-Work pattern into Og? Or

If by unit of work you mean something like a dataset/recordset then
that might be realized once I've finished plundering Sequel's code
base - but that is vapor ware at the moment.

> should I be thinking about a whole other ORM here? As for the HQL-style

Have a look at Sequel for immediate needs.  I'm hoping to incorporate
the dataset, querying, filtering and caching goodies therein.
The model management approach and syntax is quite different from Og,
but hopefully the rest of the syntax will be common (?).

> queries, I would prefer to see an embedded DSL that supported
> database-independent queries, something like LINQ meets HQL. Perhaps that's
> a separate project that would play nice with Og?

I'd be interested in hearing thoughts on Sequels approach to caching,
datasets, querying vs Og's or any other.

Cheers
Mark

Hi,

>> So, having no shame, I'll ask a stupid question:  Why Dictionary for
>> request params?   Also, does using Dictionary for some collection (
>> post/get params ) and Hash for others ( headers) risk being
>> counterintuitive?  I think it's reasonable to think of headers and
>> params as collections, and for a programmer to expect them to expose the
>> same syntax.

> Is there a reason for these to maintain order?

there _IS_ a good rason for the order:  parameter munging how I call it.
(I'm reciting from memory, bear with me).  A long time ago I created a
1000+ line test case covering the dispatcher exactly because of that
reason.

George wanted to be able to do the following:

# /foo?a=b&c=d
def foo(a, c); [a, c]; end # => ["b", "d"]

Whereas I still think even today that this is completely unnecessary,
wack, generally unclean implementation wise and leading to problems.

Without parameter munging it can be emulated this way:

def foo(a = params['a'], c = params['c']); [a, c]; end # => ["b", "d"]

But, as the story goes, George really wanted those and we finally
agreed on having it as an option, where I battled through that it
was not enabled by default, good.

Ayway, back to the Dictionary.  Hashes are unordered, leading to the
weirdest errors with parameter munging.  So, Dictionary it is until
parameter munging gets extinguished or else all hell will break loose.

Late, but anyway,

Jo