Hello Stephen,
> On Thu, May 3, 2012 at 8:04 AM, George Chatzisofroniou > <soph...@latthi.com> wrote: > >> I’m also thinking to rearrange the GSoC schedule a bit. I’ll start >> writing code on the bonding period, > > It's up to your coding mentors, but it's generally not a good idea to > try to move up the coding stage by too much. Make sure you have a > clear spec before you start coding anything, and at least a rough > sketch of a design. Without those two pieces, there's no standard to > evaluate progress, or whether your code is doing the right thing. > As wacky mentioned i'm not planning to skip any step of the process. The idea is to press myself a bit more now, so i can have some more time to study later. I should have explained myself better. >> so i can have more time during my >> university’s exams (starting on half of June). > > I'd say just take the time as needed, after negotiating with your mentors. > >> Settings >> >> The Django app should handle some configuration parameters, like: >> >> - Maximum number of the subscribers of a mailing list the user wants >> to be shown in the charts > > I don't know how feasible it would be to implement, but if you're > willing to use AJAX, you could simply build up bar and line charts on > the fly, adding "slices" of say 5 users at a time on the right side of > the chart in progress. That might be cool. It could be set in a > "viewport" and scrolled if it gets too big for the viewport. Yes, AJAX can do the job here. I will implement the AJAX bar as you described, although i think it's better to primarily have a non-Javascript output. > > >> - Month – This model will store total posts and threads for each month >> - Year – Similar to month model, this one will store total posts and >> threads for each year > > It's not clear to me why year views can't be generated as an aggregate > of monthly data? This would allow years to start with arbitrary > months without too much redundancy. Generating the year views from monthly data is some more calculations while displaying the metrics. That's why they should be stored somewhere. > >> Interface to the MM core >> >> The app needs to interact with the Mailman core. I think the best idea >> is to implement a message bus that will send a notification every time >> a message is sent (the same way an archiver works). > > Why not just use the iArchiver interface? > > I think it should be possible to have this be a standalone app serving > the list itself, or be hosted by a particular archive, which wouldn't > need to be the list host (or even run by the same organization). Yes, i agree. The iArchiver should be the origin of the interface. Thank you for your feedback, -- George Chatzisofroniou sophron.latthi.com _______________________________________________ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
