[Mailman-Developers] Architecture for extra profile info

[Richard Wackerbarth]

Yes, yes. Please re-invent the wheel once again.

And while you are at it, you might just remove the dependancies on zope and storm, etc.

I think that you are missing the point that, at this time, this is intended to provide the capabilities that MM-core chooses not to implement.
Those website components (HK and Postorius) are being driven by Django and you only make it more difficult to implement them when choose a different schema to model/present the data.

On Apr 18, 2013, at 2:29 PM, Florian Fuchs <flo.fuchs at gmail.com> wrote:

> 2013/4/18 Richard Wackerbarth <richard at nfsnet.org>:
>> On Apr 18, 2013, at 1:19 AM, Florian Fuchs <flo.fuchs at gmail.com> wrote:
>>> 3) It doesn't need Django.
>>> Since it will not deliver any HTML (except an oAuth login form -- see
>>> 5.) and it doesn't need to be integrated into any existing web site,
>>> we can choose a more light-weight framework.
>> 
>> Here I take exception. Dismissing Django is a restriction that unnecessarily affects the ease of implementation and, in the common case, complicates the integration of the functionality.
>> 
>> Although it could be implemented without Django, it could also be implemented as a Django "app".
>> An instance of a django server can then serve the functionality.  As an alternative, where appropriate, this "app" would directly "drop in" to an instance of Postorius or an enterprise website.
>> 
>> One of the advantages of Django is that it can be used as a rapid prototyping mechanism. Simplified interfaces to the data are "free" and more elaborate ones can be added in an incremental fashion.
>> Also, rather than writing custom modules for things such as authentication and REST interfaces, there is the large community of third-party extensions which readily integrate to provide that functionality.
> 
> It's not that I don't want to use Django. I just wanted to point out
> that we won't need much of it for a pure JSON API. OTOH adding a new
> dependency by using another framework is probably not a good idea
> either. So if we want to keep the number of dependencies low, the
> alternative would probably be to use no framework at all and use
> restish for the, well, REST stuff (or whatever library the core will
> be using in the future).
> 
> Florian
> 
>> I would advocate that this "User" module make it appear as if stores the entire "record" for the user.
>> In the implementation, it could actually store parts of the user information in multiple databases (one of which could be the MM-core).
> 
> +1