Thomas, > Adam you talked about implementing it with python, it will take me a lot > of time since i haven't used python before so I rather do it in Java. > But if you whant it in python fine I'll take the time and sit to to > learn python. Final result will take abit longer with python thats all.
I mentioned that Leo was looking at a mod_python implementation, and liking what he saw. I was just floating the idea, to see how interested you are. Basically, we want this project to "succeed", but success in OSS comes in many colours. ;) What we mean is that sometimes learning something new, and making an "ok" attempt at it is better for the community than doing something perfect, yet rote. (Some folks say the best OSS project is the great idea w/ the poor implementation, 'cos it attracts more community.) Would a mod_python plug-in be more fun? Maybe, that depends upon your interests. Would it have more bugs? Certainly, the framework is much younger. Which would be better for the Gump community, or ASF community, or you? Who knows, only time would tell. Sorry, I guess we are seeing that I'm going to be one of those mentors that poses more questions than answers. ;-) That all said, I'm really not pushing either approach. The Java appoach is good, and since it is easier (on you), it might dig deeper into how we can extract data from the Gump results. Basically, I'm (1) open to ideas from other Gumpers (2) willing to let you pick what you are most comfortable with. Finally, don't feel pressure on this ... we aren't looking for some fixed result, some perfectly polished webapp, we are all looking to learn from this endeavour & see where it leads us all. BTW: (all) I've also mentioned that Cocoon was likely not our favoured approach, since we don't have cycles to help you with it. > The choice of language allso depends on what server we have. We have access to a number, and folks run Gump on whatever servers they like. What do you have locally to work on? Me, I use W2K others use Linux or Mac, etc. > So whats next? > I think I need a push in the back to get started so just hit me and we'r > off. What exactly do I need to get started, do i need svn or can I get > the code through cvs? I have never used svn before so a short > introduction would be nice. ASF is migrating from CVS to SVN. Some Gump metadata remains in CVS, but won't for much longer. As such, please learn/use SVN. Using the client against ASF code (to get a local copy you can't commit back) is easy [V1]. To learn more about SVN, should you need/want, try [V2]. The Gump3 code is here [V3]. [V1] http://www.apache.org/dev/version-control.html [V2] http://svnbook.red-bean.com/ [V3] http://svn.apache.org/repos/asf/gump/branches/Gump3/ > how much of the Gump code do I need to know to do my task, Is it enough > to know what the database contains or do I need to integrate with the > rest of the program. Is the presentation a standalone webapplication? If > that is the case then I should only need to focus on the databasecontent > and the mening of it. As it is now I don't realy know what you whant me > to do and from reading some oldposts from the mailing list you don't > realy know either. We'd like you to focus on the database content, not how it gets populated, because one of the main thrusts behind Gump3 is to leverage the DB separation. Gump2 produce static HTML as it runs, and hence during a run (for many hours) the "output" is inconsistent (part last run, part this run.) We want to be able to query the data at any time, getting consistent results. There will be different "use cases" for the data, and although we can't predict them all, we can some. Some folks just want to know why their project broke, to fix it. Some will want to know about projects stability (over time) so do some historical data mining. Some will want to know about interactions between projects, "who uses my project", etc. We might want to list these use cases & plan for them. We will be improving the database schema with feedback from you, as you show us what is possible with what is there. What is there is pretty simple, but the main 'players' are in the database, so you can list projects, dependencies, and so forth. There is plenty to get started with. I'm sure you'll learn some of how Gump3 works from running it, and you'll want to run it locally so it produces a local DB of data for you to work on. You'll want Apache HTTPD v2 [R2], I'm sure. Getting things started will take a little time in itself, so do start that. [R1] http://wiki.apache.org/gump/GumpThree [R2] http://httpd.apache.org/ Please look at the static HTML pages that Gump2 generates [H1], specifically the statistics [H2] and [H3] cross reference pages and collect your thoughts on how a dynamic approach (data mining verse data overload) would be better. Having smaller/tighter pages (not pages stuffed w/ extra info) is the first win. Being able to calculate (query) a lot of the stats/cross-references is another win. Allowing folks to "easily navigate Gumpdom" through the webapp is the key. [H1] http://vmgump.apache.org/gump/public/buildLog.html [H2] http://vmgump.apache.org/gump/public/gump_stats/index.html [H3] http://vmgump.apache.org/gump/public/gump_xref/index.html Please provide a Wiki page for this project, and we'll take some of this there. I'm sure we all have a list of design requirements/constraints & they are best summarized on a wiki. Again, glad to have you on board. regards, Adam --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
