Mimi Yin wrote: > In my mind, the beauty of this approach is that anyone can process it > and add it to the calendar. At the same time, if it's spam, anyone can > get rid of it. The community of read-write sharees can work together to > maintain the collection and keep it up to date.
Yes, it is a beautiful vision. I'm concerned about feasibility and predictable behaviors. I understand how to implement shared workflow queues in centralized applications, web apps, and fast-synchronization architectures. Loosely synchronized (hourly) and disconnected operation, it's trickier because of overwrites and conflicts. I'd like to hear about how much is already coded, or already planned to be coded, in Chandler to deal with conflicts between a local change and what later gets synchronized. Last-sync-wins? I see conflicts just in mailman management, where it's all web pages, with just 2-4 moderators, and you STILL get conflicts. It is technically challenging to fully solve issues arising from conflicts when multiple parties are changing a database and you're not transactional and centralized.. > This is in contrast to email where each individual recipient has to > process/delete/manage the same piece of information. Yes, understood. So how do we address multi-party conflicting changes to the email submission queue? I posit that we have a fundamental problem doing this multi-party triage in hourly-synced Chandlers. I can currently only see how to workaround that problem by having all the submission queue management done with a centralized web app. I'm sure I'm not the first to wonder, so I'm hoping to just hear the prevailing wisdom on this issue. -- Jared _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "Design" mailing list http://lists.osafoundation.org/mailman/listinfo/design
