Both actions and input/output modules were created to overcome sitemap programmability limitations. Flow doesn't have those limitations anymore so i don't see the reason to keep those artifacts here.
What do others think about this?
I think the current community and mindshare behind flow is still too small to already start deprecating 'old-fashioned hacks' which were and still are being (ab)used a lot for the same reasons flow will be (ab)used for. Also, the continuations thing appears to be only one possible way to address the webapp dev paradigm. I don't think you are suggesting an active depreciation, but suggestions like the one above seem rather tendencious and suggestive IMHO.
OK, it is only a small quote lifted out of context, but it is a good illustration of my worry that flow, being a very interesting approach, still is _only_just_one_ approach to attack the given problem domain. As much as I'm genuinely interested in continuation-based flow, I think flow needs some more real-world usage (like Pier's case) before we consider it being part of the core features of Cocoon (on the same level of 'streamlined XML processing' and 'the sitemap'). I read the above statement as a suggestion into that direction.
If I say 'core', I mean the kind of stuff which you _have_ to use if you want to use Cocoon, not the 'blocks vs core' discussion, or 'it has an impact on the sitemap grammar'. I'm pretty sure that you don't want to see flow added to Cocoon with people openly saying 'ok', but silently thinking 'whatever, I'm going to stick to my way anyhow'.
Oh. Do please read this as a neutral observation, will you? I'm not into flames. If I'm wrong with my observation, just say so and I'll withdraw to my cave. ;-)
Cheers,
</Steven> -- Steven Noels http://outerthought.org/ Outerthought - Open Source, Java & XML Competence Support Center Read my weblog at http://blogs.cocoondev.org/stevenn/ stevenn at outerthought.org stevenn at apache.org
