In retrospect, my phrasing may have made it seem like a bigger issue then there really is, but here is my understanding of the problem: When a POST submission arrives, it's tagged with information regarding when the originating form was generated. I'm not sure where all this information is stored. It may be session or hidden form vars - I can't be sure without digging. In any case, the server then checks to make sure that the article hasn't changed since the time the form was created and alerts the user if this is the case with as "Page has been changed" message. In the case of IM or Email, there is no "originating form" - so resolving which submission came from which previous version becomes an implementation detail. In the case of Email, I suppose you could put in the email a hashcode of some kind to establish a "session" of sorts - then remember to which article and which revision that hashcode corresponds. (I'm just thinking aloud here - I'm sure others here have more info on how this could be done). Because of the very asynchronous behavior of SMTP/POP/IMAP, chances of this kind of collision are much more likely then with the wiki's web interface. The resolution is to send more emails explaining the condition and providing a resend request - or direct the colliders to the web interface. Anyway, that's just my understanding of the problem - I reserve the right to be wrong on all points :) I don't know, but there used to be Email-a-Webpage services whereby you could Email a URL as the subject line to some entity and get a response which was the requested page. I'm having trouble locating one now though ... Googling for "webpage by email" doesn't produce anything useful :( On 2/19/07, Steve Bennett <stevagewp(a)gmail.com> wrote: > > On 2/19/07, Jim Wilson <wilson.jim.r(a)gmail.com> wrote: > > Finally, in both the IM and Email cases, race-conditions become a > serious > > issue. How do you determine which publishing entity (IM, Email client, > or > > wiki user) got there first? Using a standard interface (the wiki) > > alleviates this problem. > > > I would love it if there was an email-to-wikipedia interface, mainly > because my mobile phone gives me unlimited email for free (whereas web > browsing is ridicously expensive - go figure). There do appear to be a > lot of fairly significant hurdles though: authentication, parsing > email (stripping out signatures, demangling character conversions, > avoiding accidental changing of whitespace etc), and of course the > potential for significant lag between receive and update - is merging > really a safe option when the article may have been downloaded 6 hours > earlier? > > > Steve > > _______________________________________________ > Wikitech-l mailing list > Wikitech-l(a)lists.wikimedia.org > http://lists.wikimedia.org/mailman/listinfo/wikitech-l >

On 2/20/07, Jim Wilson <wilson.jim.r(a)gmail.com> wrote: Google for "web-to-email", or take a look at this list: http://www.oscar.org.uk/about/webtoemail.htm A lot of those are no longer in operation, but I know that web(a)pagegetter.com works well. -- John

Steve Bennett wrote: If i had such free service, i'd set a server doing it for me :P If it's a 'private' service, things gets easier: -Authentication: Use a variable account name as password. -Stripping out signatures: You use the same email ssystem -> Always the same signature. Is merging really a safe option when the article may have been downloaded 6 hours earlier? If it hasn't changed, yes ;) If it's a poppular article, probably not. But merging could wait until i sit in front of a proper computer.

Steve Bennett wrote: I didn't explain well. If today you need to post by sending an email to wikipost5de133e7d(a)example.com, tomorrow to wikipostc9ece41a19(a)example.com and so on, it's higly difficult to impersonate you (without being a man-in-the-middle, which could catch your password on http, too).

Ok, well, if you're going to go for it anyway, I have these suggestions: 1) Batch Edits - Please batch together IM dialog as a single edit rather than having each new statement in a conversation be a new "Edit" to the page. This is to prevent flooding of the Recentchanges as well as the pages edit histories. 2) Consent - It would probably be good to have a way for your users to "consent" to having their IM conversations logged as wiki pages since this amounts to a sort of cyber-monitoring system. 3) Bot Edits - Depending on popularity, it would probably be a good idea to attribute these automatic edits to a bot user. This is to limit flooding of Recentchanges and watchlist emailings (if they're enabled). That's what I can think of off the top of my head. Good luck! -- Jim On 2/22/07, Dr. Robert P. Biuk-Aghai <robertb(a)umac.mo> wrote: