Re: Inversion Jonathan S. Shapiro (
Mon, 17 Apr 2000 22:24:24 -0400

I want to say that I agree completely with Brian. I also want to explore a couple of things that he raised.

> While there is merit to debating
> the specifications and requirements, I really really really do not want to
> see development discussions devolve into, for example, flame wars between
> python, perl, and scheme advocates (especially when a well-designed system
> won't have to care a whit what language the clients and servers are
> programmed in).

I agree about the flame issue. There is no such thing as a "right" language. While I personally don't care for Perl, there are a great many people out there who are fond of it, and it is inevitable that somebody will decide to implement a Perl engine for DCMS if DCMS proves useful.

That said, here are some requirements for a satisfactory scripting language:

  1. Whatever scripting language(s) is (are) integrated into DCMS must run on all platforms. I see only two reasons to build a scripting language into a CM system:
    1. to ensure that the scripts will run anywhere
    2. to ensure that differences in the environment don't alter the behavior of the CM system.

Oddly enough, one of the appeals of Scheme is that the language hasn't changed in any significant way in almost a decade. The point is not that Scheme is wonderful (the standard lacks an adequate standard library), but that backward compatibility of the scripting environment should be an overriding concern in whatever scripting language is chosen.

Issue 1(b) would rule out Java for the time being, because of portability issues with JVM's and JDK's.

2. Scripts in DCMS should not come from client-side files. Whatever scripting language is chosen, it should be possible to alter its module loading facilities to load code out of DCMS entities rather than out of files, and to outright *prevent* access to files that are not part of the configuration or the working area. The whole point of having the scripting language is to eliminate the need to run client-side code as part of a policy enforcement process. I don't think I care much what diff tool gets used, but code that checks preconditions for checkin should run within DCMS itself. It would certainly be nice if everything ran within DCMS, but I don't really want to build YAWnS (Yet Another Window System).

3. Any scripting language should have a solid sandbox with no holes. If I'm going to be able to insert code that runs on your machine, you need to be able to know who owns the machine when it is all over.

> I do not want to usurp the momentum behind Jonathan's project in the
> slightest...

I do :-) If somebody walked up tomorrow and said to me: "Here, this does what you want" I would be delighted to stop this effort. I'm not greatly into reinventing wheels. Please, will somebody ship me a wheel!

>... I'd like to make sure if our projects are different,
> it's really because we have differing goals. What is our goal?...

Actually, I think that's a good question, and that I should also try to answer it here.

In jumping off onto DCMS temporarily, here are the main issues that are motivating me:

  1. Local Development.

I work on a portable or at the wrong end of a disconnected modem most of the time. I spend a depressing amount of time on airplanes, and it's staggering how much code you can get written on one if you are really determined.

Unfortunately, I also screw up. [Yep, you heard it here. Right from the horse's mouth. Shap actually *doesn't* write perfect code the first time :-)] My personal working style really needs a system that lets me build a private branch (or more than one, when quick bug fixes are needed), hack on it for a while using local commits, and then integrate that branch (i.e. the whole sequence of changes) back into it's parent branch.

2. It seems much better to move code changes around by shipping branches than by shipping diffs. I really want to get to a place where you can build a new driver, integrate it, and email me a URL for the resulting branch and version. From this URL I should be able to get all of the associated changes, test them, and integrate them into some main trunk.

When you think about it, the "I work on a portable" example could just as well be "I work in a separate company." I want a system where a company can build a private branch of EROS and successfully keep the changes to the base system merged into their private version.

An implication of this is that I want local private branches.

3. I want to have authentication. This is mainly a requirement for security certification, but it's really important to know who did what when something goes wrong.

4. I want the basic semantics right. Rename and history are important. Both should work.

5. In doing all of this, it's really important to preserve a certain conceptual simplicity, for obvious reasons. The thing needs to be usable!

Though I'm learning something in the process of thinking through branch and merge, I continue to believe that the basic semantics of the operations isn't all that hard. Doing good delta management is extremely complex. Deciding what the actual entities are doesn't look like it should be. Doing distribution is mildly tricky. I'm really hopeful that if I can build a naive repository with a good API, somebody like Josh will call me up, tell me what an idiot I am for not using the obvious tool, and between us we'll get a great repository plugged in. More on this in a moment.

Part of this is that I'm about to get into a situation where several companies are building on EROS while a shared development process is simultaneously underway. I've used CVS across corporate boundaries (or tried to), and it didn't work for us because there wasn't enough ability to generate agreement across the repositories.

So in rough terms, that's why I'm looking into this.