> 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.