GSoC Project Discussion - Web Posting Interface.
Peter Markou writes:
Now regarding Richard's email, "GSoC Applicants". After having a comprehensive examination in Hyperkitty I found that the functionality for posting messages through web exists.
I think it should be split out as a separate Django app, independent of HyperKitty.
I agree with Steve. One of the advantages of Django is its "mix and match" capability. Actually, I see two possible apps. One would integrate with HK. The other would be simpler, just providing a posting mechanism that provides authenticated message sender.
On May 8, 2013, at 10:19 AM, Stephen J. Turnbull <stephen@xemacs.org> wrote:
Peter Markou writes:
Now regarding Richard's email, "GSoC Applicants". After having a comprehensive examination in Hyperkitty I found that the functionality for posting messages through web exists.
I think it should be split out as a separate Django app, independent of HyperKitty.
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/rkw%40dataplex.net
Security Policy: http://wiki.list.org/x/QIA9
In practical terms, I think the time would be better spent on integrating HyperKitty and Postorius for Mailman suite *first* and then dividing out the posting capability once the integration is done. That way the person who does this has some idea of the pain points of integration so they can be better smoothed for the next piece.
Terri
On 05/08/2013 09:31 AM, Richard Wackerbarth wrote:
I agree with Steve. One of the advantages of Django is its "mix and match" capability. Actually, I see two possible apps. One would integrate with HK. The other would be simpler, just providing a posting mechanism that provides authenticated message sender.
On May 8, 2013, at 10:19 AM, Stephen J. Turnbull <stephen@xemacs.org> wrote:
Peter Markou writes:
Now regarding Richard's email, "GSoC Applicants". After having a comprehensive examination in Hyperkitty I found that the functionality for posting messages through web exists.
I think it should be split out as a separate Django app, independent of HyperKitty.
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/rkw%40dataplex.net
Security Policy: http://wiki.list.org/x/QIA9
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/terri%40zone12.com
Security Policy: http://wiki.list.org/x/QIA9
On May 08, 2013, at 10:31 AM, Richard Wackerbarth wrote:
I agree with Steve. One of the advantages of Django is its "mix and match" capability. Actually, I see two possible apps. One would integrate with HK. The other would be simpler, just providing a posting mechanism that provides authenticated message sender.
The real power here would be for someone who is reading the archives to "jump into" a discussion, potentially long after the fact. Imagine you've done a web search for a particular problem you're having and it lands you on a page in an archive. You want to follow up to that message with some additional information or question. Reducing the burden for that type of intermittent involvement in a topic should be the goal.
-Barry
On 05/09/2013 12:28 PM, Barry Warsaw wrote:
The real power here would be for someone who is reading the archives to "jump into" a discussion, potentially long after the fact. Imagine you've done a web search for a particular problem you're having and it lands you on a page in an archive. You want to follow up to that message with some additional information or question. Reducing the burden for that type of intermittent involvement in a topic should be the goal.
A simple step toward this goal would be to add a mailto link on the message's archive page that includes an In-Reply-To field, as outlined in the "Basic Examples" section of the Mailto RFC:
https://tools.ietf.org/html/rfc6068#section-6.1
so something like:
<a href="mailto:list@example.org?In-Reply-To=%3C3469A91.D10AF4C@example.com%3E">Reply to this message</a>
While this doesn't solve the problem for everyone (i'm sure there are MUAs that don't accept this header when generating mail from a mailto: link), it should be very easy to implement, and if mailman's default archives were to include such a link it would spur people to fix non-compliant MUAs.
Regards,
--dkg
On 05/09/2013 09:47 AM, Daniel Kahn Gillmor wrote:
so something like:
<a href="mailto:list@example.org?In-Reply-To=%3C3469A91.D10AF4C@example.com%3E">Reply to this message</a>
Go to <http://mail.python.org/pipermail/mailman-developers/2013-May/023054.html> and look at the mailto: link under 'dkg at fifthhorseman.net'.
While this doesn't solve the problem for everyone (i'm sure there are MUAs that don't accept this header when generating mail from a mailto: link), it should be very easy to implement, and if mailman's default archives were to include such a link it would spur people to fix non-compliant MUAs.
Granted, it doesn't say "Reply to this message", but it's been that way for years.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Hi Mark--
On 05/09/2013 01:06 PM, Mark Sapiro wrote:
Go to <http://mail.python.org/pipermail/mailman-developers/2013-May/023054.html> and look at the mailto: link under 'dkg at fifthhorseman.net'.
wow, great! I have never looked at this link before because i always assumed it was a link to e-mail the original sender of the message.
i'm sorry i missed it. I've been a mailman user for over a decade now (and a mailman admin for at least half that) :/
Granted, it doesn't say "Reply to this message", but it's been that way for years.
I probably wouldn't have missed that i could use that link to reply to the message if the link text had been "Reply to this message" :)
All the best,
--dkgOn 05/09/2013 10:31 AM, Daniel Kahn Gillmor wrote:
On 05/09/2013 01:06 PM, Mark Sapiro wrote:
Go to <http://mail.python.org/pipermail/mailman-developers/2013-May/023054.html> and look at the mailto: link under 'dkg at fifthhorseman.net'.
wow, great! I have never looked at this link before because i always assumed it was a link to e-mail the original sender of the message.
It can be that. If the global setting ARCHIVER_OBSCURES_EMAILADDRS is True (the default) the text will be of the form 'user at example.com' and the link will address the list. If ARCHIVER_OBSCURES_EMAILADDRS is False, the text will be of the form 'user<at-sign>example.com' and the link will address the user, but in either case, the In-Reply-To= and Subject= fragments will be included.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Barry Warsaw writes:
On May 08, 2013, at 10:31 AM, Richard Wackerbarth wrote:
I agree with Steve. One of the advantages of Django is its "mix and match" capability. Actually, I see two possible apps. One would integrate with HK. The other would be simpler, just providing a posting mechanism that provides authenticated message sender.
I'm not sure what you're proposing in terms of "integration". The way I see it, is HyperKitty or any other app could provide links which could invoke the web posting app or the user's MUA. The web posting app would have an URL like
http://list.example.com/HyperKitty/post/MSG_INIT_INFOwhere MSG_INIT_INFO would have the same format as a mailto: URL. So, HyperKitty would be in a good position to generate References and so on for any message in the archive, but other apps would be able to generate their own special messages. Eg, Roundup could put issue refs in posting URLs it puts in issue pages.
Barry Warsaw writes:
The real power here would be for someone who is reading the archives to "jump into" a discussion, potentially long after the fact. Imagine you've done a web search for a particular problem you're having and it lands you on a page in an archive. You want to follow up to that message with some additional information or question. Reducing the burden for that type of intermittent involvement in a topic should be the goal.
I think there's something to what you say, but it's not obvious to me how much easier that would be than a mailto: URL. I think basically the use case is for people who want an integrated interface to the list in their browser.
On May 9, 2013, at 12:06 PM, "Stephen J. Turnbull" <stephen@xemacs.org> wrote:
Barry Warsaw writes:
On May 08, 2013, at 10:31 AM, Richard Wackerbarth wrote:
I agree with Steve. One of the advantages of Django is its "mix and match" capability. Actually, I see two possible apps. One would integrate with HK. The other would be simpler, just providing a posting mechanism that provides authenticated message sender.
I'm not sure what you're proposing in terms of "integration". The way I see it, is HyperKitty or any other app could provide links which could invoke the web posting app or the user's MUA. The web posting app would have an URL like
http://list.example.com/HyperKitty/post/MSG_INIT_INFO
where MSG_INIT_INFO would have the same format as a mailto: URL. So, HyperKitty would be in a good position to generate References and so on for any message in the archive, but other apps would be able to generate their own special messages. Eg, Roundup could put issue refs in posting URLs it puts in issue pages.
Steve, what you are describing is a possible form of the "integration" that I suggest. However, there may be much more information that should be included. As an example, one might want some kind of automatic "seeding" of a part of the message based on the content of the message referenced Another possibility would be a way to avoid extending some of the links from a multi-linked message. I don't know enough about the details avail to attempt to provide a more precise description. However, we need to keep the "level of integration" issue open until someone (presumedly the student) completes an inventory of reasonable possibilities.
I was contrasting that situation with another which simply provides an authenticated submission of a message.
My point is that these two (and others) need not be mutually exclusive.
Richard Wackerbarth writes:
However, we need to keep the "level of integration" issue open until someone (presumedly the student) completes an inventory of reasonable possibilities.
I would like to leave that up to Peter. (We should avoid burdening the students with chores like inventorying possibilities, unless it helps them decide requirements, design the application, and code the implementation.)
BTW http://tools.ietf.org/html/rfc6068 describes the mailto: URI. It's remarkably flexible, although the body does present some special problems.
Yes, I, too, would leave it to Peter. And I am not suggesting that he attempt to make any complete "inventory". But I don't see how you can possibly "decide requirements" without taking them into consideration.
On May 9, 2013, at 1:58 PM, "Stephen J. Turnbull" <stephen@xemacs.org> wrote:
Richard Wackerbarth writes:
However, we need to keep the "level of integration" issue open until someone (presumedly the student) completes an inventory of reasonable possibilities.
I would like to leave that up to Peter. (We should avoid burdening the students with chores like inventorying possibilities, unless it helps them decide requirements, design the application, and code the implementation.)
BTW http://tools.ietf.org/html/rfc6068 describes the mailto: URI. It's remarkably flexible, although the body does present some special problems.
participants (6)
-
Barry Warsaw -
Daniel Kahn Gillmor -
Mark Sapiro -
Richard Wackerbarth -
Stephen J. Turnbull -
Terri Oda