Re: [Mailman-Developers] Architecture for extra profile info
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@gmail.com> wrote:
2013/4/18 Richard Wackerbarth <richard@nfsnet.org>:
On Apr 18, 2013, at 1:19 AM, Florian Fuchs <flo.fuchs@gmail.com> wrote:
- 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
2013/4/18 Richard Wackerbarth <rkw@dataplex.net>:
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.
I don't want to re-invent the wheel and I don't advocate dismissing Django. Django is probably perfect for the prototype. It might also be perfect for the final thing. But we don't know what database we're gonna use in the end (which determines if the Django ORM still fits), or if we'll use many HTML templates etc. If we end up not using many of the things that make Django great, we might wanna think about if we want to use it. And might still come to the conclusion that we do. All I'm saying is: The environment for such an app could be a little different to Postorius/HK, so let's spend some thought on it. Is this such a bad idea?
Florian
participants (2)
-
Florian Fuchs -
Richard Wackerbarth