In the new runtime, a storage volume is a physical container for holding data. Examples of storage volumes include PC cards and communicators. A storage volume includes some memory, which can be RAM, ROM, or both. A storage volume is analagous to a metacluster in the old runtime. Since PC cards are now storage volumes, the PC card header contains an offset to a volume header instead of to a metacluster.The high level PCMCIA classes have been reworked in Rosemary. The CardSlot class had a lot of code that was specific to RAM/ROM cards. Most of that code has been moved to the StorageCard (formerly PCCard) and StorageCardServer classes. CardServers are no longer required to create PCCard objects.
Rosemary makes it easier for card servers to be notified about slot events. CardServer subclasses can override CardInserted(), CardRemoved(), or CardWriteProtectSwitchState() operations to be notified when any of these events occur. The framework for supporting other card events is in place in the low level CardSlot class, but not implemented in the CardServer interface.
Removed the code that dealt with a card being half inserted into a slot, and the associated silly emergency images.
Renamed class PCCard to StorageCard and removed class MagicCISHeader.
Moved StorageContainer_CardBatteryState to class StorageCard. Moved clean up of removed packages from CardSlot_CardRemove to class StorageCardServer, making ejecting non-storage cards much faster.
Now that the storage card has been abstracted from the card slot handler, code that used to iterate through iCardSlots to find storage card volumes should iterate through iStorageCards instead.
Storage cards now have a header written at the beginning of their common address space, instead of adding a CIS tuple. This means that 1.x PC cards will not be compatible with Rosemary Magic Cap devices.
The process for searching for a card server that wants to claim an inserted card has been modified. Now, two passes are made. Once through a list of storage card servers, then another pass through a list of generic card servers. This allows a card server that has its own driver on the card to be installable.
In Magic Cap 1.x, you would use a call from the preferred family to respect New Items Go Here. In Rosemary, the preferred calls have been removed. Instead, pass the indexical value iNewItemsGoHere as the nearThis parameter of one of the near calls. An alternate form is to use the result of NewItemsNear as the nearThis parameter. This routine returns either iNewItemsGoHere or cluster containing the exampled object passed to this routine. The difference in behavior in the near calls is that by passing iNewItemsGoHere directly, the new object will be created in the system persistent cluster if the new items package is not activated. NewItemsNear checks for this case, and returns the package persistent cluster if the new items package is not active.
ROM PC cards will not be supported in Rosemary.
The new hardware reference does not have a switch to detect if a PC card is "half in" so the code that worried about whether or not a PC card is half in has been removed. The single interface that publicized this, Object_CardHalfInserted, has been removed.
To handle transfer of data from 1.x PC cards, added the CompatibilityCardServer class which handles old format PC cards being inserted. Conversion classes will convert objects in data packages on these PC cards into new data packages. Class TranslationEngine does the work of translating objects on PC cards formatted the old way into new packages. When the user inserts an old style card, a window comes up telling the user that this card doesn't work, but they can translate the contents of the card. Tapping the translate button brings up another window that allows the user to decide where the translated information should go.
Instances of the following classes are translated:
AbstractClass AddressCard Animal AOLLabel ATTMailLabel ATTSkyTelPagerLabel Authenticator BitmapFont BookPage BorderLine Card City ClassName Cluster Currency Code Color CompanyPostalLabel CompuServeLabel ConcreteMeans ConcreteObject DataPackage DeliveryReportCard DialupIPMeans EditableList ElectronicMailService ErasableAnnotation Facility FaxLabel Folder FontDescription Form FrozenObject GroupAddressCard Image InternetMailLabel LANMeans List ListCard ListEntry Locale MagicmailName MCIMailLabel Means MIDISong MiniCard Multicode NameCard NameKey NoteCard NumberingPlan Object ObjectList OctagonShapeType OctectString OvalShapeType PermitClassNumber PhoneCallCard PhoneLabel PlatformDescription PolygonShapeType PortalFacility PostalLabel ProdigyLabel ProviderAddressCard ProviderLabel RadioTelescriptLabel RectangularShapeType RMLabel Scribble Sound Style SummaryCard Task TaskEditor Teleaddress Telecard Telename Telenumber TelescriptLabel Text Ticket Time Viewable UnsharedImage Way X400Label
The phone is a separate module in Rosemary. The phone classes have been reworked to keep the hardware support for telephony separate from classes that are related to the phone user interface. The PhoneStatus and PhonePanel classes implement the basic telephone user interface in Magic Cap.The PhoneResource class arbitrates between various clients that wish to use a particular phone resource. Classes that wish to use phone resources should inherit from PhoneResourceClient. Class PhoneResourceClient defines the API that allows a phone resource to arbitrate between clients of that resource. While packages might create PhoneResourceClient subclasses, it would be unlikely that a package would create actual phone resources.
PhoneAudio is a PhoneResource subclass that handles low level operations relating to the sound chip, such as dial tone monitoring, volume control and muting. PhoneAudio subclasses can implement other phone audio services, such as a voicemail navigation system.
PhoneDialer is a PhoneResource subclass that handles phone number dialing.
PhoneCircuit is a PhoneResource subclass that handles the hook and connected state of the phone. PhoneCircuit subclasses handle different types of phones. For example, classes LandLineCircuit and CellularCircuit implement a wireline phone and a cellular phone respectively.
Class PhoneEventClient defines the interface for classes that wish to respond to phone events, such as the phone ringing, being taken off hook, or establishing a connection.
The abstract class PhoneServer defines the API for initiating phone activities, such as dialing and answering calls, as well getting and setting phone attributes, such as volume level and muting. Different Magic Cap implementations will have different concrete subclasses of PhoneServer that provide the interface to the low level phone functionality.
The Rosemary Magic Cap API tries to avoid having multiple operations have the same name but different interfaces. Since Magic Cap doesn't do polymorphism, this is just plain confusing. Many operations have been removed or renamed to avoid this problem. Changed the Hookswitch() attribute to be Boolean to match other definitions of Hookswitch(). All occurences of Entity() in Magic Cap are now attributes. Some classes had defined two operations, Entity() and SetEntity().
The auto-formatting of phone numbers has been restricted to reduce the instances of accidental recognitions. A minimum of seven digits is now required before any formatting is done.
It is possible to have more than one phone server object present in the system, to deal with multiple telephony devices (built in land line and a PC cellular card, for example). Because of this, use of iPhoneServer is discouraged. Instead, use First(iPhoneServerList).
Added new methods PhoneResource_CanAllocateResource and PhoneResource_ResourceHardwareAvailable so that clients of a phone resource can make sure that the resource is available before trying to use it. These new methods obsoletes PhoneAudio_Available.
Added PhoneServer_CanInitiateCall which makes sure the phone line isn't already in use before trying to dial a number. PhonePanel_StartPhoneCall calls this operation before doing anything.
The phoneLabel field in the HasPhoneLabel mixin class is now a strong field; objects referenced by this field are now considered owned by instances of classes that inherit from HasPhoneLabel. This means that if you have an object that is referenced from multiple objects, and one of those references is in contained in this field, this object will no longer exist after destroying the HasPhoneLabel object.
Renamed the field SpeedDialButton_telenumber to _globalPhoneNumber.
Renamed the operation PhoneField_CreateNewCard to CreateNewCardFromPhoneNumber() and removed the second parameter and return value which were never used.
Phone dialing is now done asynchronously, on a different anchor. This allows the user to stop or mute a dialing-in-progress.
The battery server class has been rewritten and immensely simplified. This change makes the battery server and the main and backup battery servers use strictly voltage (as opposed to milliamp counting) in determining the battery level.Wake up events have been cleaned up in the process of bringing up the MIPS hardware platform. Renamed [Set]DeviceWakeUpEnabled() to [Set]WakeUpEventEnabled() and ResetDeviceWakeUp() to ResetDeviceWakeUpEvents(), which should make the use of these methods clearer.
The PowerAware class has been refined. The functionality encapsulated by PowerAware has been split across three classes, WantsPowerEvents, UsesExtraPower and CanPreventSleep. This split makes it much clearer what aspect of power management a class is interested in and what needs to be implemented. It is no longer necessary to observe iPower and iPowerSupply. Instead, classes now just need to override the proper methods to get just the power events they're interested in.
Classes which inherit from these new power mixin classes must also inherit from HasReinitialize.
The Load() method has been renamed Reinitialize(). The class HasLoad has been renamed HasReinitialize. The operation formerly known as Load() is no longer declared as noMethod. This allows classes to inherit from HasReinitialize (and call InheritedReinitialize()) regardless of whether any superclasses have also overridden Reinitialize(). This means that you must call InheritedReinitialize() in your override of this method.