Abstract
This memo tells how to rebuild Alpine's bcds from their Cedar sources. It is implementor documentation; consult HowToAdministerAlpine.tioga
for instruction on how to start up and run a server.
Finding files
Files related to Alpine are stored in a number of directories. The server and client code is built on a set of shared interfaces which are released as part of Cedar in [Cedar]<Cedar6.0>AlpineShared>* and controlled by [Cedar]<Cedar6.0>Top>AlpineShared.df. The client code is released as part of Cedar in [Cedar]<Cedar6.0>AlpineUser>* and controlled by [Cedar]<Cedar6.0>Top>AlpineUser.df. The server code itself resides in [Indigo]<RAlpine>Server60>* and is controlled by [Indigo]<RAlpine>Server60>Top>AlpUmbrella.df. DF files for Alpine clients such as Walnut, Yodel and whiteboards import from AlpineShared and AlpineUser.
AlpineShared
AlpineShared contains the interfaces and implementations shared between the clients and the servers, together with their RPC stubs. There are five public interfaces, i.e. interfaces for remote access from workstations: AlpineTransaction, AlpineFile, AlpineVolume, AlpineOwner, AlpineDebug. In addition, AlpineEnvironment, a types-and-constants-only module, resides here, as does AlpineTransMgr, an interface used between Alpine servers to manage distributed transactions.
To establish context,
% CD ///AlpineShared/ -- the name is up to you
% Bringover [Cedar]<Cedar6.0>Top>AlpineShared.df
The public interfaces must occasionally be recompiled, generally due to Cedar changes. Most often the recompilation will not affect the format of calls on the wire, hence will not require the client implementations out in the world to change. Very occasionally the public interfaces will change in an incompatible way. Then you must not only recompile, but change the version stamp on the interface and distribute new client software to the world. Everything in AlpineShared is properly remade by MakeAlpineShared.cm.
You change the version stamp by editing AlpineRemoteExportImpl. You increment each half of AlpineRemoteExportImpl.version by one, then save the file.
If you are recompiling the public interfaces, you must be sure that the bcds of the same names (AlpineEnvironment.bcd, AlpineFile.bcd, etc) do not exist in the root directory; otherwise Lupine will become confused. Then
% AddDebugSearchRule ///AlpineShared/ -- to help Lupine
% MakeAlpineShared
When you are done
% SModel AlpineShared
% VerifyDF AlpineShared
AlpineUser
AlpineUser contains interfaces and implementations needed by clients of alpine. In addition to the RPC implementations of the shared Alpine interfaces, there are "object-oriented" (well sort of) versions of the same interfaces (e.g. AlpFile is an object-oriented AlpineFile) that are somewhat easier to use. AlpineUser also contains the directory software for Alpine clients. We are currently in the process of moving from the AlpineInterimDirectory package to the AlpineDirectory package, so at the moment, both are incorporated in AlpineUser.
To establish context,
% CD ///AlpineClient/ -- the name is up to you
% Bringover [Cedar]<Cedar6.0>Top>AlpineUser.df .
Make sure that any changes you have made to AlpineShared have previously been SModelled so that the bringover will fetch them. Everything in AlpineShared is properly remade by MakeAlpineUser.cm.
% MakeAlpineUser
When you are done
% SModel AlpineUser
% VerifyDF AlpineUser
AlpineServer
To establish context,
% CD ///AlpineServer/ -- the name is up to you
% Bringover [Indigo]<RAlpine>Server60>Top>AlpUmbrella.df .
To rebuild the server implementations, whether or not you have recompiled the public interfaces,
% MakeAlpineInternals .
It is possible that MakeDo, invoked inside MakeAlpineInternals, will complain about a syntax error in either LogMapImpls.Config or FilePageMgrImpls.Config. This is acceptable, as long as AlpineCommonImpls.bcd and AlpineServerImpls.bcd actually get rebuilt.
When you are done,
% SModel AlpUmbrella
% VerifyAlpine -- "VerifyDF AlpUmbrella" does not work very well
Alpine and the Cedar release
There are tradeoffs involved in incorporating components of Alpine in the Cedar release. On the one hand, more and more programs are clients of Alpine, and expect the stability they get from knowing that the interfaces are release items. On the other, Alpine is still evolving, often at a greater rate than Cedar releases can be made. The organization of Alpine into AlpineShared, AlpineUser and AlpUmbrella as it stands now, is a compromise between these positions. The clients get released interfaces and client-machine implementations, but the server code is not part of the Cedar release, so it is easier to change.
Unfortunately, we still have not converted the bulk of our users to AlpineDirectory. This requires changing not interfaces so much as bits on the disk of the server. This will soon require a delicate balancing act as we release a new AlpineUser that uses AlpineDirectory and simultaneously convert the directory formats on the servers' disks.