The compatibility mode attempts to emulate the AFP 2.4 environment. Under most conditions you will not notice any difference even if not all characteristics of AFP 2.4 could be recreated. In principle, the compatibility layer is made up of three elements:
The plug-in C24_Fox.EXE provides a FOX object that re-routes all requests to the correct objects of the AFP3. FOX.GetFormVar(), for instance, is emulated through the following code:
Procedure GETFORMVAR
LParameter tcName
Return REQUEST.Form(m.tcName)
Access and Assign methods are used for the numerous properties. It is for technical reasons that the FOX object is somewhat slower than the access to the relevant AFP object itself. Other than that no further differences exist. This means you can use this object also in a pure AFP application if this suits you better and/or use the AFP3 objects in an application running in compatibility mode.
For the emulation of the environment, however, the FOX object alone won't suffice. There is also the file C24_Fox.afpa. This is an entirely normal AFP 3 application that is installed in \AFP3\C24. You will find this application in afp.config in the top of the virtual directory tree. For this reason this application will be used automatically unless you assign your page to a different application. When migrating an application you can copy and customize this particular application. In fact this is the method we recommend for migration.
The tasks of C24_Fox.afpa can be quickly summed up. It evaluates the AppID parameter, provided one has been delivered; it crosses over to the directory of the AFP page, runs application.prg and, if applicable, takes care of the localization via the command ??. The latter is possible by using separate functions in C24_Fox.afpa.code to create output.
Whilst these two components are dependent on each other, C24_Cookie.EXE is independent of both. Actually, AFP 3.0 uses a session ID with 44 digits that is based on a GUID. With a probability of virtually 100 percent, this value will remain unique well past the year 3000, and it wouldn't be easy to guess. In addition, the ID is handed over as a normal parameter in conformance with the Internet definitions. The standard name of this parameter is sid; in most configurations it has been changed to afpcookie. You may change the name in afp.config across the board.
The plug-in ensures that AFP 3.0 will re-adopt the old system. The session ID will be attained through SYS(2015). This may cause conflicts if two AFP instances create a session simultaneously. In addition, the function yields an ID that is easy to guess, making it relatively easy for attackers to locate the session of another user. The reason we separated these functions from the rest of the system was that for the avoidance of conflicts between instances or of security problems you might want to quickly change over to the new method without having to re-arrange the entire code. In such a case, just change all links from
<A HREF="page.afp?!<%?FOX.cCookie%>">Link</A>
to
<A HREF="<%?Session.Url("page.afp")%>">Link</A>.
Session.Url() always returns the URL in correct format, regardless of whether you used the old or the new method. Once you have changed all pages remove the plug-in from the configuration, re-start the AFP and benefit from the longer session IDs.
On the other hand, it may well be that your system uses the session IDs. If it is too much effort to adjust the table structure etc. you may leave the plug-in loaded in order to make use of the old session ID model even in pure AFP 3.0 applications.
The compatibility layer does not mean that AFP 3.0 will now act as AFP 2.4. The entire AFP 3 functionality remains available at all times. You may also copy C24_Fox.afpa and C24_Fox.afpa.code and make your own adjustments. This will give you the opportunity to implement the migration at your own pace. A first step would be to test existing applications under AFP 3.0. If everything goes smoothly you can take your time about the migration, as even code written for AFP 2.4 fully benefits from the advantages of AFP 3.0.
If you do a complete migration, your sole benefit will be enhanced security and speed –security on the grounds that the new session IDs are more secure, and speed due to the fact that access to the FOX object is slower than the direct access to AFP 3.0 objects. Don't overestimate the importance of the latter, though. Any SQL query will be slower than access to the FOX object in a complete page.
In the same manner, any access to Application.prg will slow down the compatibility layer. If you started the conversion by copying the file C24_Fox.afpa to your application directory, you should adopt all code in Application.prg to the corresponding methods of C24_Fox.afp.code and subsequently remove all code for the invocation of Application.prg from Event_PageCallBefore.