I guess maybe I should have been more precise in what I was complaining about. I don't know much about SM's domain model, and I don't care: that's an implementation detail of the service. What I care about is the service's API. So if it's possible to take SM's existing domain model, and SM's existing data, and just replace the HttpView stuff with some new API (that's actually documented!), then great! Less work for Chris Cunnington to do!
Yes, the HttpView is the part that needs replaced. THAT is what provides the service API and the implementation details we don't care about whereas the domain model is the "gold" of the system -- the nougat that needs wrapped in a new server. Not only is it possible to keep the existing domain model whole, it is _essential_. There may be some tweaks we can make to it in the future (like maybe removal of the "published" flag) but we should just focus on the server implementation details right now.
The other thing I think is important is to not _lose_ too much functionally just for the sake of a "new" server. The current server, for all of its faults, supports quite a bit of interesting capabilities such as the replication of the model to the client for offline use, and backup of external sites download links in case they go away, among others..
The main point to my reply was that I'd like to see Chris Cunnington supported in his experiments around SM, and I'd like to see Chris Muller sleeping easily at night knowing that our core infrastructure isn't going to be ripped apart during said experiments.
As a dedicated volunteer, my primary goal orients around the end-results for Squeak. Certainly I like my beauty sleep and I want CC to be supported if his goal's are the same. But doing the work is no guarantee of acceptance, which is why it's good to engage community apriori.