On 5/31/07, Morgen Sagen <[EMAIL PROTECTED]> wrote:
Yes, so I was asking why wouldn't the server itself be the thing to triage untriaged items?
because the server should be a dumb repository, not something that takes action to arbitrarily change data without a client being involved. we could certainly make a simple, default-value-setting rule like "any item that is stored without a triage status has it automatically set to NOW". choosing whether or not to change an item's triage status based on how much time has elapsed since the last time an item was stored, or anything of any greater complexity of the setting of a default value at creation time, is a client's responsibility, not the server's.
So I asked what about the case where a large number of items are all in the DONE bucket? Doesn't that have a similar traffic problem?
yes, and we have options as to how to display those items in the web ui. i don't recall specifically what we decided last week, but i think we at least strongly considered only showing the most recent n DONE items. something like that. but, while the amount of data that is transferred between the server and the client is part of the issue, it's not the entire issue. the amount of post-processing that has to be done on the client after it gets the data, and the number of updates it correspondingly has to send back to the server, are also concerns. _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "Design" mailing list http://lists.osafoundation.org/mailman/listinfo/design
