However, I wouldn't exclude the possibility of writing special clients if functionality required it (and I'd write them in Tcl/Tk, for portability).
I would argue strongly that special clients should not be required or provided. Once you provide them, then there is a temptation to implement functionality in them that is not available in the web clients, and I believe that in this day and age there is very little that cannot be done with cleverly designed web pages and server side software.
I agree with both your arguments against special purpose clients: those are excellent reasons to try to avoid them. However, until we know the requirements we can't say there won't be some strong requirement that can't be implemented with a web browser, and if that were to happen, I'd want to solve the problem with Tcl/Tk (in preference to Java, by the way). I'd happily start working the details out based on an 'Any Browser' constraint (see www.anybrowser.org) for the user interface. Aiming everything at a browser might unnecessarily contrain user interfaces too: for example, we might more easily do a 'drag-n-drop' interface in Tk than as a web page, and (IMHO) Tcl/Tk is lighter weight than Java for this sort of thing. I can also do simpler editing interfaces with Tcl/Tk (no need to refresh a page when I edit or create an item), using the same HTTP transactions that a clunky web interface would use. Bob Gautier Ateb Limited