On 9/17/05, David Baird <[EMAIL PROTECTED]> wrote: > On 9/17/05, Dave Howorth <[EMAIL PROTECTED]> wrote: > > Peter Speltz wrote: > > > What exactly does this get us if it does work agian? Does it add any > > > extra features, flexibility, security? :) > > > > I second this question. Dave B raised an interesting curiosity question > > about what two lines of code do. I for one assumed it was a continuation > > of previous conversations about simplifying the Maypole code. But some > > subsequent proposals seem to have left complexity unchanged, or even > > increased it. So like Peter, I'd like to understand the motivation > > behind such proposals? > > > > There's a few things floating in the ether at the moment. I think the > main drive is to make the code more maintainable, at least that's > where my own current interest lies. There's a lot of highly concise > code in Maypole. Every time I need to look at it, I spend a lot of > time just figuring out how it's supposed to work, before I can start > figuring out how to implement my own stuff around it. The version that > Dave H posted a couple of days ago improves some parts, I've been > working on some other parts, I'll post it soon.
Maintainability is vital for us to meet the goals for the roadmap. We are already on our 5th Maintainer and although Dave and David have been contributing to the project for a long time we don't have any of the early key developers on board such as Simon Cozens, Marcus Ramburg or Sebastien Riedel. Fortunately Simon is still using Maypole a great deal and maintains a more than healthy interest and is quite accessable for tricky questions, even if he is no longer subscribed to the lists or watching the wiki - it is always worth forwarding stuff to him if we are stuck or wondering why - he usually has a good explaination and can point either at what he wanted to do or say stuff like 'yeah, that was for something that never appeared' or whatever. Its probably worth compiling a list of the questions bandied around in recent discussions at simon - if you collect the ones that have bugged you I'll email simon and make sure I get a response. > Then there's been talk about a few new features. > > I've been blue-skying about some sort of workflow object or state > machine, but that's not likely to happen, it's just thinking aloud. I > wrote some pseudocode, which helped me clarify my understanding of how > Maypole works, then I ditched it because it was overkill. Its probably worth looking at the workflow for version 3, which I imagine will be possibly late 2006 or so. I'd like to keep Maypole 2.x backwards compatible to both the API, documentation and Tutorials/Wiki/List archive through it's lifetime and major reworking of workflow will have a huge impact on that. > There's also a roadmap at http://maypole.perl.org/?TheRoadmap. We've > not made too much progress on it yet, I suspect because hacking > Maypole is *hard*. If we can simplify the core, we might make more > progress on the new features. Definately true - if we can document and tidy the internals it will make a big difference to maintainence and the ability to fix bugs as well as add new features. Also I don't like stunt perl, 'magic' and hacks where they can be avoided. Cheers, A. ------------------------------------------------------- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php _______________________________________________ Maypole-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/maypole-devel
