Terri, For Systers, is it better to try to access Postorius through its REST API or by directly including it as a django app?
In particular, using Django 1.5 and the custom user module feature that it provides along with the scheme that I outlined earlier provides an easy path to developing and integrating features such as the essays into the user profile. Basically, we share a common User model. Someone can start by using the standard django.contrib model and ignore the Postorius specific parts. I am willing to implement the pieces (I estimate needing only a day or two if I do a simple version), but I also think that it would be an appropriate task for one of the students. Richard On Apr 30, 2013, at 10:31 AM, Terri Oda <te...@zone12.com> wrote: > On 13-04-29 11:28 PM, Stephen J. Turnbull wrote: >> Actually, there aren't any students explicitly discussing extra profile >> information in their proposals. They talk airily about "extended REST >> API" or similarly generic terms. None talk about storage or >> representation of profile information. (OK, it was 3am, my memory is >> fallible. I don't remember any, though.) >> > > Oh! I think I understand some of the confusion now. I thought I'd said at > the beginning why I was starting this thread at all, which is primarily > because Systers has a student project that needs extra profile info. There > are also a collection of students with minor features that would use the data > store that they've used to pad out projects that might otherwise be too short > (For example, see some of the ideas Peter Markou mentioned in his recent > post). But now that you mention it, I've been talking to a lot of folk on > IRC and they often don't tell me if they're applying with Mailman or Systers, > so maybe there's more of them with Systers than with Mailman? > > > For those not familiar, Systers runs a heavily modified version of Mailman > 2.1. They'd like to switch to Mailman 3 shortly after we release Mailman > Suite (whenever that's going to be), but they've got a few features that > they'll need to either have integrated to core Mailman or maintained as > branches. This year, they've got a project set up to port one of them to > Mailman 3/Postorius as part of preparing them for that. > > The specific feature they're hoping to add this year stores essays that > people write when they subscribe. It's currently done with a database > grafted on to Mailman 2.1 that was being used for another extended feature, > but obviously if we're going to mentor such a project for Mailman 3, we'd > like to use something at least approximating a real data store design. The > problem is that the Systers mentors are mostly used to systers-mailman, based > on 2.1, and I'm not sure anyone will have the Mailman 3.0 knowledge to guide > a student through a halfway reasonable design, so I asked here in order to > help them out so that their student could start on the essays (likely to be > the easier part of her project) right at the beginning of the GSoC period. > If we can't come to a moderate consensus on that design, I should be telling > the Systers folk that this project won't be able to run this year, but I > honestly figured we'd have a simple design after a couple of posts... I > wasn't counting on aut hentication blowing up to a huge argument, and I don't have time for it do so if we want to make a good decision about this specific project. > > So yeah, totally cool to be thinking about the more advanced projects in > general, but I started this thread due to a specific need for a "good enough > approximation for this Mailman suite release" version of the extra data > store, and I still need a consensus on that that's either implemented or > simple enough for a student to do in the first week of GSoC. I think we're > pretty close to that point, but I'm not sure it's yet described in a way that > we can hand it off safely to a student and get a REST API that actually > meaningfully matches the discussion within a couple of days. Probably we > need an actual set of doctests for the student to work against next and then > we'll be there. > > Incidentally, I've been trying to get the students interested in this > particular Systers project to come to this mailing list and join in the > discussion, but it's become *very* intimidating to take part in this thread, > which is the other reason I need folk to take a step back. > > Terri > > _______________________________________________ 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
