Stephen,
I'm not advocating that Postorious be THE keeper of the user information. But
it would be a good candidate for the job.
What I am advocating is that the "core" message handler NOT be the keeper of
ONLY PART of it.
I am perfectly happy to have the user info handled by an independent
s
Richard Wackerbarth writes:
> What I am advocating is that the "core" message handler NOT be the
> keeper of ONLY PART of it.
What I'm advocating (mildly, because somebody else is going to have to
do the work) is that the core be the keeper of ALL of it. The core is
not just a "message handler
On Jul 11, 2012, at 8:14 AM, Stephen J. Turnbull wrote:
> Richard Wackerbarth writes:
>
>> What I am advocating is that the "core" message handler NOT be the
>> keeper of ONLY PART of it.
>
> What I'm advocating (mildly, because somebody else is going to have to
> do the work) is that the core be
On Jul 11, 2012, at 1:55 AM, Terri Oda wrote:
> * We'd also like to do openid, which means we need to somehow associate an
> openid token with an email address.
>
> So right now, postorius needs email address, username (for direct
> authentication), and potentially a list of openid or other tok
Hi there,
Am 11.07.12 15:34, schrieb Richard Wackerbarth:
> On Jul 11, 2012, at 8:14 AM, Stephen J. Turnbull wrote:
>> Richard Wackerbarth writes:
>>
>>> What I am advocating is that the "core" message handler NOT be the
>>> keeper of ONLY PART of it.
>>
>> What I'm advocating (mildly, because som
The problem in splitting data is that links between the various related entries
need to be maintained.
This means having the ability to go from one entry to the related ones, and
back again.
When the data is stored in multiple tables, foreign keys provide the link. When
both tables reside in the
Florian Fuchs writes:
> But I also agree with Terri that there might be a good amount of user
> data used by Postorius, Hyperkitty or any other web ui/client that just
> doesn't have anything to do with mailman's core tasks. And I don't see
> why something like "preferred ui theme" or profile-
Richard Wackerbarth writes:
> Pretty soon, you will find that what you need approaches something
> that already exists -- a relational database. Rather than
> "reinventing the wheel", we should just use an already existing
> database system and make all of the data directly accessible.
We're
On Jul 11, 2012, at 12:50 PM, Stephen J. Turnbull wrote:
> Richard Wackerbarth writes:
>
>> Pretty soon, you will find that what you need approaches something
>> that already exists -- a relational database. Rather than
>> "reinventing the wheel", we should just use an already existing
>> databa
Richard Wackerbarth writes:
> No! Although you are making available (some/most/all) of the data
> values, you are not making available the ability to make arbitrary
> SQL-type queries to view the data.
AFAIK the plan is to do that via the REST interface. I don't see why
they need to be "arbit
On Jul 11, 2012, at 3:29 PM, Stephen J. Turnbull wrote:
> Richard Wackerbarth writes:
>
>> No! Although you are making available (some/most/all) of the data
>> values, you are not making available the ability to make arbitrary
>> SQL-type queries to view the data.
>
> AFAIK the plan is to do tha
Thanks for starting this discussion. Since the thread's already long, I'm
just going to answer randomly with my own thoughts.
One thing I have a real problem with is defining the database query layer as
the interface between components. To me that just unacceptably ties us to a
specific database
On Jul 10, 2012, at 10:51 PM, Richard Wackerbarth wrote:
>Yes, it is a bug in Postorius. However, that does not negate the fact that
>the present design, by forcing a split database, makes it difficult to
>accomplish the desired behavior.
Why exactly is it difficult? I'm not trolling, I really w
On Jul 11, 2012, at 02:12 PM, Stephen J. Turnbull wrote:
>But isn't that going to take us a long way down the road where we
>anoint Postorius the one-and-only admin interface? If that really
>needs to be, OK, but I don't much like it.
I don't either; it's unacceptable.
Many, maybe most, sites w
On Jul 11, 2012, at 05:39 AM, Richard Wackerbarth wrote:
>I am perfectly happy to have the user info handled by an independent
>stand-alone module which is willing to take responsibility for ALL of the
>user profile info. It should provide a REST interface that allows other
>modules the ability pe
On Jul 12, 2012, at 02:50 AM, Stephen J. Turnbull wrote:
>It's not the same argument. A mailing list needs a message
>distribution agent; it doesn't *need* a webUI.
+1
Or I might rephrase that as: it doesn't need *a* webUI :).
Postorius rocks, and it is going to be a fantastic piece of the def
On Jul 11, 2012, at 02:22 PM, Richard Wackerbarth wrote:
>No! Although you are making available (some/most/all) of the data values, you
>are not making available the ability to make arbitrary SQL-type queries to
>view the data.
Which frankly, I don't think we should do, in the core. The core is
aAt Thu, 05 Jul 2012 09:24:33 +0900,
Stephen J. Turnbull wrote:
> [...]
> Newsgroup names are an issue here. It seems to me that (if not
> gateway'd to Usenet) they should be something like (pseudo-code)
>
> "mailman." + join(reverse(split(list-id,".")),".")
>
> Eg, this list would be "mailm
On Jul 11, 2012, at 05:04 PM, Richard Wackerbarth wrote:
>As an example, suppose that I want to have an "intelligent" ToDo indicator.
>As a minimum, I need to be able to get from the data store a list of MLs that
>have pending requests AND for which I am authorized to do that work.
>Typically, thi
On Jul 12, 2012, at 02:50 AM, Stephen J. Turnbull wrote:
>Nevertheless, it would be preferable if that is wrapped in an API that
>makes it look like it's all coming form one place, and which manages
>the linkages so that data is not store redundantly in different
>places, or inaccessible to certai
On Jul 11, 2012, at 09:27 AM, Richard Wackerbarth wrote:
>First, we should define all of the data storage in terms of the REST access
>points to the data. (And not, as presently done, the other way around) Next,
>we should access all of the REST interface URLs indirectly so that
>functionality can
On Jul 11, 2012, at 9:05 PM, Barry Warsaw wrote:
> Thanks for starting this discussion. Since the thread's already long, I'm
> just going to answer randomly with my own thoughts.
And thanks for your reply. I just spotted something in it that makes me feel
that rather than fundamental disagreeme
22 matches
Mail list logo
