Which would be a good thing in and of itself, as a matter of software design, even if no-one planned on ever writing new clients. But the ability to write new clients (or change the existing one for private use, if it is open source) is much more important.
The two aren’t contradictory or unrelated :-) More to the point, the idea of multiple interoperable clients is hardly a “new way for humans to collaborate”, or even just “new”.
At this level of abstraction what is it that you want to change? LW does have an API expressed through HTTP and we have multiple interoperable clients called “browsers”.
Like I said, I have no idea how far LW is from having a good API already. (Not all HTTP traffic is a proper API, but maybe it’s a well written site.) If an API already exists, so much the better; move on to step 2.
By “client” I mean the actual client-side content and code of the website, or a client application for non-browser implementations. Not the browser (or equivalently, the OS).
Error, if I understand correctly, seems to want the ability to modify the UX and add new clientside features, with different users (like Error) choosing different features, and without requiring the server to be changed, everyone to agree, and the people who can actually change the server to spend time on it. If this is indeed Error’s main motivation, I suggested that it might be more easily (almost unilaterally) achieved by writing a new client. The new client might be web-based or not; that’s unimportant to the argument.
At this point, is LW itself anything more than a database with a schema? You’re pushing pretty much everything into the client.
Which would be a good thing in and of itself, as a matter of software design, even if no-one planned on ever writing new clients. But the ability to write new clients (or change the existing one for private use, if it is open source) is much more important.
Yes, but we’re leaving the territory of “let’s make LW work well” and entering the territory of “let’s design a new way for humans to collaborate”.
The two aren’t contradictory or unrelated :-) More to the point, the idea of multiple interoperable clients is hardly a “new way for humans to collaborate”, or even just “new”.
At this level of abstraction what is it that you want to change? LW does have an API expressed through HTTP and we have multiple interoperable clients called “browsers”.
Like I said, I have no idea how far LW is from having a good API already. (Not all HTTP traffic is a proper API, but maybe it’s a well written site.) If an API already exists, so much the better; move on to step 2.
By “client” I mean the actual client-side content and code of the website, or a client application for non-browser implementations. Not the browser (or equivalently, the OS).
Error, if I understand correctly, seems to want the ability to modify the UX and add new clientside features, with different users (like Error) choosing different features, and without requiring the server to be changed, everyone to agree, and the people who can actually change the server to spend time on it. If this is indeed Error’s main motivation, I suggested that it might be more easily (almost unilaterally) achieved by writing a new client. The new client might be web-based or not; that’s unimportant to the argument.