Indexicals are currently used for two purposes: being able to refer to an object from C code (linking) and being able to dynamically change the object to which an indexical is referring (indirection). These concepts will become independent in Rosemary. Both of these concepts will still be supported, but the current implementation of indexicals (lists of lists) will change.In current versions of Magic Cap, indexicals are defined with the MakeIndexical() family of macros in C header files. The Rosemary version of Magic Cap introduces a new way of declaring and initializing indexicals.
Indexicals will be declared in class definition files using the following syntax:
indexical indexicalName : class [, readOnly]
Indexicals will be initialized in object definition files with this syntax:
indexical indexicalName = (object reference);
The new format makes indexicals full fledged types in Magic Cap C instead of being abstracted bit shift expressions. This allows objects referred to by indexicals to be type checked at compile time.Even though the implementation of indexicals will change, the symbolic names defined in Indexicals.cdef will still be used to represent the objects they refer to. As long as you use these symbolic names, and do not use indexicals that don't have a symbolic name defined for them, references to system indexicals in your code should not be impacted by this change. Similarly, symbolic names should be used instead of the double brace format for package indexicals.
The new indexical definition format obsoletes the MakeIndexical() macro family. This means that indexical values can no longer be calculated inline in C code.
Rosemary provides a new way of installing new values into indexicals. In Magic Cap 1.x, the preferred way of replacing an indexical value was to call System_InstallInto. Rosemary introduces a new class, IndexicalInstaller, which handles all the details of installing new values into indexicals. IndexicalInstaller defines two operations, InstallIndexical() and InstallMultipleIndexicals(). InstallIndexical() is the way to install a new value into a system indexical. InstallMultipleIndexical() installs into system indexicals specified in a list. The list should be a list of paired entries, with the first entry specifying the indexical to change and the second entry specifying the new value.
Changed the interface of SetIndexical() so it returns the old value of the indexical. Using iIndexicalInstaller is preferable to calling SetIndexical(). It is illegal to pass an ephemeral object to SetIndexical.
In Magic Cap 1.x, the meanings of the first twenty four root list entries in a software package are defined by the system. Because indexicals are simply indirect object references in Rosemary, there are no system defined package indexicals. Some of the package indexicals defined in Magic Cap 1.x were never used; others have been moved into fields of the Rosemary SoftwarePackageContents object, which are accessible through attributes:
Indexical Field Attribute iPackageHelpOnObjects helpOnObjects HelpOnObjects(), readOnly iPackageStandardPlaces sceneIndexicalList SceneIndexicalList() iPackageStacks stackIndexicalList StackIndexicalList() iPackageStartupScene startupScene StartupScene() iPackageStartupItem startupItem StartupItem() iPackageCreditsScene creditsScene CreditsScene() iPackageLogo logo Logo() Package help objects used to be maintained by two indexicals, iPackageObjectsWithHelp and iPackageHelpOnObjects. These two lists have been combined into one list of paired entries referred to by SoftwarePackageContents_helpOnObjects.
The messages that are displayed when a package is packed or unpacked used to be referenced by the indexicals iPackagePackMessage and iPackageUnpackMessage. Unlike other package indexicals that have been folded into the software package object, there are no fields to refer to these messages. If you want to customize these messages in your package, you need to subclass SoftwarePackageContents and override PackMessage() and UnpackMessage().
One package indexical that may have been useful but is no longer defined is iSoftwarePackage, which was a reference to your software package object. You can obtain a reference to your package's SoftwarePackageContents object in Rosemary by calling PackageContents(Context(object)), where object is any object in your package.
Several indexicals have been removed because they referred to objects that were being referenced by other indexicals. Removed the iCommandBar alias for iControlBar. Removed iAutoCopyConfirmationWindow as it was an exact duplicate of iConfirmationWindow. Removed iBigConfirmationWindow since it just pointed at iConfirmationWindow. Removed iBigPersistentConfirmationWindow, iScreenLocations, iCardServerNeeded, and iUntimelyCardRemoval. Removed iMailFolders synonym for iReceivedMailFolders. Removed iPackageOutOfMemory synonym for iSystemOutOfMemory. Removed iPackageUnknownException synonym for iSystemUnknownException.
ProviderAddressCards are no longer used to describe service providers; the new class ServiceChoice is now used. Removed indexicals that referenced provider address cards: iBeamProviderCard, iSendingMailProviders and iCollectingMailProviders.
Added the indexical iDialingLocationSetupPlace. This is the place that lets the user sep up the dialing location. This indexical was added to separate the phone user interface from the dialing location interface.
iMiniCardStack is an ObjectList. It used to be a Stack.
Added the indexical iNotifyCurrentUserChangedList. Objects in this list will have their CurrentUserChanged() method called when the current user of the device is changed.
Made the iOrderedTestStyleList, which is used by the resize-textstyle-to-fit feature be a list of indexicals.
Added iBook8.
Added iCurrentDialingLocation.
Added iGenericMiniCardImage.
Added iSkyTelPagerDescription so that SkyTel pagers have a description that is distinct from the generic "pager". Added special edit steps for pagers to iSpecialAddressInfoDescriptions and iSpecialAddressInfoEditSteps.
Added iAttributeStepListChain which stores step lists and their targets. This replaces the obsolete iLastEditStepList.
Added "every TTh" and "every MWF" to iShortRepeatTypes.
Added iTaskTextMapping to iTelecardTextMappings so that telecards can take advantage of datebook specific text mappings.
Added iNewItemsGoHere. This is passed to NewNear() and CopyNear() to specify that objects should be created in the preferred container.
Added iAlternativeHolidayTask.
Added iInternetProviderPrototypes.
Added the exception iCannotEncodeCharacter for alternate character set encoders to raise if they cannot encode the input text.
Added the exception iCannotAllocateMemory, which replaces the last lightweight exception, cannotAllocateMemory.
Added iCurrentMailSummaryChoice and removed the obsolete iSummaryPlaces and iMailboxSummaryScene. Option tapping the "report" button in the in box takes the user to the scene referenced by iCurrentMailSummaryChoice.
Removed iGoToSummaryButton.
Removed the obsolete indexicals iUserPowerDOwn and iDevicePoweringDownWindow.
Removed iDeathStar.
Removed iDefaultInputBoardModeForLetters.
Removed the indexicals related to the revert feature: iRevertChoices, iRevertPrompt, and iSystemDateRecord.
Renamed iCanCollectCondition to iCanCollectMailCondition.
Renamed iCollectingMailServices to iEnabledCollectingMailServices to make it clear that this is a list of enabled mail service choices. This list is now a ServiceChoiceList object.
Renamed iFaxDeliveryChoiceImage to iFaxPostageImage
Removed iNeedsAddressCardWindow since it referred to the same object as iHelpFillOutUserCardWindow.
Removed iTaskTextMappingTemplates.
Removed script editor indexicals iPrototypeScriptEditor, iScriptEditor, iScriptField, iCurrentScriptMenu, iOnStatement, iScriptListWindow, iPrototypeScriptCoupon, iSelectForScriptTool, iTinkerScriptCoupon.
Removed Telscript related indexicals iTelescriptError, iIncompatibleCloudVersion, iAuthenticationFailed, iTelescriptFailure, iCertificateTimeOutFailure, iDefaultCloudMessageForm, iTelescriptPlaceList.
Removed iAddressCardsByLetter, since the contents of this list is really associated with the address cards master list. Use ComponentsLists(iContactsMasterList) instead.
Removed the obsolete iDirectConnectEditSteps andiDirectConnectImage.
Removed iMultipleNameCardsImage. Use iManyNameCardsImage instead.
Removed iMIMECharsetJIS.
Removed iOfficialSeal, which was a stamp of the certified name card image. This was never used.
Removed iBillingAddress because it only allowed billing in the United States.
Renamed iCloudDown to iServiceDown to make it non-Telescript specific.
Renamed iVendorProviderContact to iVendorContact.
Renamed iSlashText to iDialOutPrefixSeparatorText.
Removed iCurrentEditList which was only used by BookOfListsPage.
Several indexicals have been renamed to better clarify their use. Others have been replaced by other indexicals.
Old indexical New indexical iAccessibleGroups iGroups iCardSlots iStorageCards iCDRomXACompression iADPCM4bitHQCompression iChangedLocales iChangedDialingCountries
iChangedToDialingCountriesiCollectingMailProviders iCollectingMailServices iDrawTool iThinBlackPenTool iEnabledServicesList iEnabledCollectingMailProviders iMailServiceProviders iSendingMailProviders iCurrentLocale iCurrentDialingCountry iDeleteNumberingPlanPrompt iDeleteDialingLocationPrompt iDescriptionList iStandardLabelDescriptions
iStandardPhoneDescriptionsiEditedNumberingPlan iEditedDialingLocation iEnabledCollectingMailProviders iCollectingMailServiceChoices iFolderLists iFileCabinetDrawers iJobAndCompanyEditSteps iJobCompanyAndCountryEditSteps iJobCompanyAndCountryEditSteps iDescriptionJobCompanyAndCountryEditSteps iLoadList iReinitializeList iLocaleEditSteps iDialingCountryEditSteps iLocales iDialingCountries iLocalTimeZone iHighlightedCityImage iNoMoreFound iNoMatchingItems
iNoMatchingItemsInSceneiNumberingPlan iDialingLocation iNumberingPlanImages iDialingLocationImages iNumberingPlanStamp iDialingLocationStamp iOrchestra iDefaultOrchestra iOriginalIndexicalValues iIndexicalInstaller iPackageObjectsWithHelp
iPackageHelpOnObjectsiPackageHelpOnObjects iPhoneDAA iPhoneServer iPhoneIcon iPhoneIconImage iPhoneImages iStandardPhoneImages iPreferredServiceProvider iPersonaLinkProvider iPrototypeLocale iPrototypeDialingCountry iPrototypeNumberingPlan iPrototypeDialingLocation iRAMCardServer
iROMCardServeriMemoryServer iSendingMailProviders iSendingMailServices iStandardSceneIndexicalList iSceneIndexicalList iStandardStackIndexicalList iStackIndexicalList iTextLists iTextToMeasureForStorageView iTextMappingList iTelecardTextMappingList iUnknownText iUnknownPersonText
iUnknownTimeTextiUserPurgers iLowMemoryPurgers iUserPurgeWindow iDailyPurgingWindow
The proprietary beaming protocol used in the first generation Magic Cap communicators has been replaced with the IrDA industry standard. There are now two major components to the infrared port in Magic Cap. The first is the IrDAStream class, which is a new subclass of CommunicationStream. The second component is an application that uses IrDAStream to implement Magic Cap beaming as an ElectronicMailService.IrDAStream is built upon IrLAP, IrLMP and TinyTP. IrLAP is the link layer, and is not yet IrDA-compliant: the initial connection is made at 115.2 kbps while the standard specifies a connection at 9.6 kbps, with rate negotiation as part of the initial handshake. IrLMP implements the multiplexing/demultiplexing functions of IrDA version 1.1. The IAS data base services or IrLMP are not implemented in Magic Cap; the results of the discovery process are recorded in a list of Contacts instead. Only the byte stream service of TinyTP, not the full sequenced package service is implemented.
IRMeans now supplies a serial server as the driver, not iMagicBeam.
Infrared beaming is handled by a new actor class, IRActor. This actor is responsible for sending and receiving ISO-type protocol messages. All IrDA is now done through a message-like interface defined by IRActor. To create a buffer for a new infrared message, call IRActor_NewMessage. To send the message, call IRActor_SendMessage. To destroy the buffer, call IRActor_DestroyMessage.
With Rosemary, Magic Cap will be broken up into modules so that it will no longer be one monolithic piece of code. By breaking portions of Magic Cap into separate packages, installation issues will arise as packages try to install objects into other packages which have not been activated yet. Rosemary overcomes this problem by making the simplifying assumption that objects in the install list now know inherently where they should be installed. Doors know that they should install into the hallway, buildings know they should install downtown, icons know they should install into their native container.To avoid the problem where a package tries to install objects into a place that hasn't been activated yet (imagine trying to install a door when the hallway isn't there yet), packages should never install objects directly into places. Instead, packages should specify iInstallationQueue as the receiver for these objects. Magic Cap will tell objects in this list to install themselves after all packages have been activated.
Some types of viewables don't have a concept of where they should be installed. For example, cards don't know which stack they belong in; they are installed in the correct stack by specifying the stack in the receiver list. It is possible that a stack of cards is now part of a module. To specify that a card should go into a particular stack of cards once that stack is present in the system, you can create an instance of class InstallSpecifier which should be installed into iInstallationQueue. This object is analagous to an install/receiver pair in a 1.x software package. Installation queue entries can also be used to override an object's desires about where it wants to be placed or how the fallback should be handled.
Entrances are viewables which lead someplace else. Examples of entrances are doors and buildings. Entrances must mix in with Entrance and override DefaultReceiverForSelf() to specify where the entrance should be installed. Class Door is a subclass of Entrance that installs instances into the hallway. Class Building is a subclass of Entrance that installs instances downtown.
Viewables which can have entrances installed must mix in with CanContainEntrance. Classes which used to override InstallInto() to install instances should now override InstallEntrance() instead. This means that it is no longer possible to install into any arbitrary viewable.
CanContainEntrance implements the method CreateEntrance() which asks a scene (or window or whatever) to create an appropriate entrance that leads to a destination. By default, this routine makes an icon based on the indexicals iGenericIconImage and iPrototypeIcon. Class Corridor overrides this method to create doors. Class Road overrides this method to create buildings.
The functionality provided by the gotoActionSelector field of software packages has been improved, but the field itself has been removed. Magic Cap unwraps to the location specified by the startupScene field of the software package object. Magic Cap further draws attention to the item specified by the startupItem field. These two fields are normally set up by the system.
The install and receiver lists in the software package have been merged into one list of paired entries. This list is referenced by the field installationList. Code that directly walked the install list to search for an item should now use the method SearchForInstallee(), which returns an index to an item to be installed. If you really want to work with the list of items to install, or the list of receiving objects, use the new methods InstalleeList() and ReceiverList(). These routines return ephemeral lists of just installees or receivers.
The maintenance of the installation list is now handled by the PackageContents class. This allows customization of how install entries are handled by creating subclasses of PackageContents.
Many classes used to override InstallInto() and have an instance install into itself so that it can execute custom installation code. Rosemary introduces the mixin class CanInstallSelf which provides this functionality. Usually, classes that inherit from CanInstallSelf will simply override DefaultReceiverForSelf() to specify where the object should be installed. For finer control of an object's installation process, subclasses can override InstallSelf(). The default implementation of this method calls InstallSelfIntoWithFallback() using the default receiver for the location and self as the fallback handler. You should almost always override InstallSelfIntoWithFallback() or FinishInstallingSelf() instead of overriding InstallSelf() unless you want to completely disable fallbacks and alienate anyone who might want to call InstallSelfIntoWithFallback() directly. If the receiver of an installation list entry is nilObject, InstallSelf() is called on the installee. InstallSelfIntoWithFallback() will call the receiver's InstallInto() method if the receiver exists. If the receiver doesn't exist, this method calls InstallSelf() on the fallback handler unless the handler is self, in which case InstallFallback(self) is called instead. FinishInstallSelf() is called after a successful installation to do something interesting after an object has been installed.
InstallInto() is still responsible for actually putting an object where it should be. Many additional InstallInto() methods have been defined in Magic Cap to allow packages to install into. DeskScene_InstallInto handles installing viewables behind the main desktop. MagicWindow_InstallInto handles installing category boxes. Drawer_InstallInto allows a package of stamps to install stamps into the stamps drawer. New flags specify whether the stamps should go into the main drawer bank or if a new bank should be created.
The parameter list for InstallInto() has been simplified. The flags and parameter parameters are no longer passed. The packageInstallList parameter which has never been used, has also been expunged. The installFlags, installParameters and installTargets fields of the package root list have also been removed. These flags were mostly used for installing tools and commands. Two new classes have been introduced to take over this functionality. Class CommandInstallSpecifier is a wrapper which allows you to specify flags as you install a global command into the magic lamp. To install a global command in the normal way, you install it directly into iCommandWindow. To install a communication command or an authoring mode only command, wrap the command inside a CommandInstallSpecifier and have it install itself, or into iCommandWindow. Class ToolPage is a subclass of Box which has an authoringMode flag. To install a new page of tools, install an instance of this class into itself or directly into iToolWindow.
Rosemary provides a new way of installing new values into indexicals. In Magic Cap 1.x, the preferred way of replacing an indexical value was to call System_InstallInto. Rosemary introduces a new class, IndexicalInstaller, which handles all the details of installing new values into indexicals. IndexicalInstaller defines two operations, InstallIndexical() and InstallMultipleIndexicals(). InstallIndexical() is the way to install a new value into a system indexical. InstallMultipleIndexical() installs into system indexicals specified in a list. The list should be a list of paired entries, with the first entry specifying the indexical to change and the second entry specifying the new value.
Packages now specify their scenes and stacks in the sceneIndexicalList and stackIndexicalList fields of the software package object. When a package is unpacked, the scenes and stacks in these fields are automatically installed into the iSceneIndexicalList and iStackIndexicalList indexicals in the system.
Scene additions are installed differently. To install a scene addition, install the object directly into the scene. Depending on the type of object, the system will put it where it thinks it should go. To gain finer control (for example, if you want to specify that an addition should be added to a specific page of a modal scene or that your addition is an authoring mode only addition), the object should be wrapped inside a PerSceneInstallSpecifier. This class is a subclass of InstallSpecifier, so you can specify a fallback location for your scene additions.
Install(), Reset() and Load() have been renamed to make it clearer what these methods are for. Install() has been renamed ReinitializeClass(). Load() is now Reinitialize(). The iLoadList indexical has been renamed iReinitializedList, and the HasLoad mixin class has been renamed HasReinitialize. Reset() has been renamed to ResetClass().
These three methods are called in a different order in Rosemary. ReinitializeClass() and ResetClass() are first called for all system classes. Reinitialize() is then called for system objects. After that, each package has its classes installed into the system class lists, but ReinitializeClass() is not called. When the system is done booting, only activated packages will have their ReinitializeClass(), ResetClass() and Reinitialize() methods called. In Magic Cap 1.x, these methods were called on all packages, regardless of whether or not they were active.
It is now possible to install arbitrary viewables into scens and corridors. In addition, it is now possible to install an item into a corridor at a specific height if you perform the installation from code.
The new class StampBank provides a simple way of installing entire banks of stamps.
Removed the flags parameter for InstallingInto().
Making Magic Cap international means removing assumptions about where text data is stored, displayed or entered.Text data cannot be assumed to be ASCII data only; characters in other languages cannot be represented by ASCII values. Characters of certain languages cannot be expressed in eight bits of data. For this reason, Magic Cap will store full 16 bit representations of character data.
String lists, which are used most frequently to store object names, now hold 16 bit characters. String lists store strings as a length byte followed by 16 bit characters. The length byte describes the length of the string in bytes, as opposed to characters. This means that strings stored in string lists can be a maximum of 127 characters long. (Each character is two bytes long, so the length must be an even number of bytes. The largest even value that can be represented by a byte is 254. At two bytes per character, this is 127 characters.)
The Character data type holds Unicode characters. The operations for classifying characters have been moved from classes Text and Utilities to class Character. The operations Character_CharacterIsRoman and HasText_HasNonRomanCharacters allow you to check whether a text object has any characters that cannot be displayed on Magic Cap systems that have only Roman fonts.
Rosemary provides a framework for character encoding translations and transliteration. The class Transcoder is the abstract superclass of all kinds of translations between character encodings or transliterations within one encoding. The HasTranscoding mixin defines the the interface for maintaining a list of transcoders available in the system. The SystemTranscoder class is a concrete subclass that handles all built-in encoding translations. Currently, this class handles translation between one byte encodings and Unicode.
The Magic 8-bit conversion routines have been reimplemented as operations of SystemTranscoder. Removed support for the Magic 8-bit character conversion routines. You should always use the string conversion routines. Removed character constants for the Magic 8-bit encoding.
Localized versions of Magic Cap will have localization packages that contain implementations for localized sorting and searching, numeric formatting and date and time formatting.
Rosemary provides a mechanism to identify the localized version of a localizable service. The new mixin class HasLocale defines the LocaleCode() attribute which consists of an ISO639 language code and an ISO3166 country code. These can be used by clients of localized sevices to verify the localized version of a service they're using. The text comparison, number formatting, name formatting, and date and time formatting classes in Rosemary inherit fromthis class and override this attribute to provide the proper information.
Rosemary provides a new text input method framework to support handwriting recognizers for Japanese communicators. This framework consists of three abstract classes, TextInputConverter, HandwritingRecognizer and PatternMatchingEngine.
The Japanese locale package also defines several classes to support handwriting recognition. Class HandwritingBoard is a general purpose input board class for handwritten characters. Class HandwritingTool is a drawing tool that updates the screen canvas while drawing and notifies a target when the scribble is complete.
Rosemary implements a new framework for entering and editing international postal addresses. There are now two ways to edit a postal address. The fancier way shows up if the user holds the option key when tapping on the address or chooses the "other" address stamp. Code can also get to the fancier method explicitly. The simple way does not let you change the description of the address, and uses the appropriate steps for the country that the address already specifies or the last one used when making a new address. (The last country used is stored in iLastCountryEntered.) The fancier way to edit a postal address allows you to change the description of the address, and prompts for a choice of country before the street address, city, state, zip, or equivalent information. After choosing a country, the edit steps for editing the address are determined based on the country. If there are no specific edit steps for this country, iDefaultPostalEditSteps is used. This is a single step with a big empty multi-line text field in it.
The NameFormatter class defines the interface for creating names from the name parts contained in contact addresses. Class NameFormatter is abstract; different locales will provide localized implentations of the API defined by NameFormatter. The class SystemNameFormatter provides a default implemntation of these routines. The name formatting methods of class Utilities, which were very American-centric, have been removed. These include LastNameIfFirstLast(), FlipNameIfLastFirst(), and the infamous EnglishPluralNounHack(). These have been replaced by SystemNameFormatter_ParseName.
The concept of first name and last name have been replaced with given name and surname, since first name and last name mean different things in different countries.
The new mixin class HasSortText allows objects that have a sort name different from their name to still sort properly. HasSortText is a simple mechanism that allows Japanese objects to use kanji in their names to sort by their kana readings. Instances that don't need a different sort name can set the sortText field to nilObject.
The class CaseConverter defines the API for localizable uppercasing. Magic Cap provides the class SystemCaseConverter with the default implementation. The indexical iDefaultCaseConverter references the default instance of this class. SystemCaseConverter uses a localizable table that defines the uppercase mappings for all characters that are mapped one to one. It may also have a multiline text object describing initial strings that should be uppercased entirely even if the caller only asks for the initial capitals; this handles the Dutch "ij" that is always mapped to "IJ". SystemCaseConverter also handles four precomposed Unicode characters that have different uppercase and titlecase variants.
The system locale object specifies which way the title reads on book spines: titles read from top to bottom in Anglophone countries, but from bottom to top in Francophone countries.
Rosemary provides support for many of the standard Internet protocols, such as TCP/IP, POP and SMTP.TCP/IP support is built into Rosemary. PPP support has been completely reworked for Rosemary. The class PPPClient has been removed. The GMTP protocol has been reworked to sit above this new code.
Rosemary provides hooks for managing data link servers so that they can be deduced from Means instances, be located by class, and be reference counted for potential sharing among packages. MagicMail and the link interface have been changed to allow the use of shared data link servers.
Rosemary has a new building downtown called the Internet Center. This building is where users will go to configure Internet providers. The Internet Center displays information specified in InternetProvider objects. The InternetProvider class defines the connection options available for contacting an Internet provider, as well as the Internet services the provider offers.
The InternetServiceChoice class represents unique combination of service client, service provider and service configuration. Lists of service choices are often generated to allow the user to select a preferred route for communication.
Added a new class, DNSResolver, that uses the Internet domain name service to map host names to IP addresses and vice versa. It can be accessed by the indexical iDNSResolver. The resolver is invoked by IPSwitch_MakeIPAddress, unless its argument is a dotted decimal address. iDNSResolver is now a static instance instead of being created by IPSwitch_Install.
The hostname and port fields of instances of TCPStream must now be set up before calling TCPStream_Connect.
The serialServer field has been moved into class DataLinkServer instead of being defined by subclasses, and has been renamed driver. This could be any type of underlying stream/packet/etc. driver.
Instances of PPPServer are now set up through Init parameters. The parameter block for PPPServer can pass a driver, userNamePAP and passwordPAP. Instances of SLIPServer are also set up through Init parameters.
Removed the DialupTCPMeans class. Packages know they need to create a TCPStream object without being told by the Means object. DialupIPMeans should be used instead of DialupTCPMeans.
Added the fields driver and image to class Means. Removed the methods DataLinkClass(), PrepareLinkLayer() and StartLinkLayer() methods. Renamed StreamEnabled() to DriverEnabled() and Stream() to Driver(). Added PreflightForDataLink() and NewDataLink().
Renamed PPPServer_userNamePAP to PPPServer_accountName and PPPServer_passwordPAP to PPPServer_password.
Renamed class DataLink to DataLinkServer.
ICF encoding has been removed from Rosemary.
Magic Cap 1.0 included classes to support the IXO pager protocol. The implementation of these classes were not complete and have been removed from the Rosemary interface.