PAMD ATAM – 5/24/02

Business Presentation:

Business Goals:

- Exploratory effort

- Simplify communications between applications on the Palm

- Easily extend functionality of the Palm

- Build reference (demonstration) application

- Has to be developer friendly

- Create a Palm based plug-in architecture

- Plug-ins must be robust

Qualities:

- Availability – PAMD can’t crash. Difficult to accomplish because users can configure or otherwise screw with PAMD.

- Usability – Easy to use for developers, Transparent to users

- Performance – Good enough response time. Remain within resource constraints.

- Portability – portable across Palm OS from 3.1, up to, but not including Palm OS 5 (4.X).

Scenarios generated/fined during session:

#1. An application requires the services of a plug-in. The plug-in requires the services of yet another plug-in. PAMD is able to start both plug-ins in the right order, and connect them to the application and return control/data to the application correctly. (H,M)

#2. A non-PAMD aware application can be made to use PAMD plug-ins within 2 person-days. (H,M)

#3. An application requires a plug-in. PAMD generates a list of compatible plug-ins. After a user selects the plug-in, PAMD loads the plug-in and transfers control to the plug in 3 seconds not including user selection time. (H,M)

#4. A user tries to execute a deleted plug-in from an outdated plug-in list. The error is handled gracefully by PAMD by notifying the user and sends an error to the application. (M,H)

#5. A user has a Palm with OS version 4.0 and attempts to beam PAMD to another user with a Palm with OS version 3.1. PAMD works the same way on both systems. (H,H)

#6. A user has a Palm with OS version 4.0 and attempts to beam PAMD to another user with a Sony with OS version 3.1. PAMD works the same way on both systems. (H,H)

#7. Assume that “phone book” and “email” are separate applications on the Palm. A user wants to send email to a person in the phone book application. PAMD allows the user to select the person from the phone book application and PAMD transparently passes the email address and control from the phone book to the email application. (H,M)

Scenario Analysis:

Scenario # 1. An application requires the services of a plug-in. The plug-in requires the services of yet another plug-in. PAMD is able to start both plug-ins in the right order, and connect them (one to the application, one to the plug-in) to the application and return control/data to the application correctly. (H,M)

Risks:

- There are no rules or guidance that indicate what functions are in plug-ins and what functions are in applications. Might complicate development of plug-ins and PAMD aware applications.

- It’s unclear what happens when code for a plug-in is loaded twice. Behavior is unpredictable. Not yet decided if cyclical references will be allowed.

- It’s unclear what would happen if the operation described by the scenario was interrupted (perhaps by a timeout). May go back to the Application, the state of the plug-ins/application would be unknown, and the data will be lost.

Scenario #2. A non-PAMD aware application can be made to use PAMD plug-ins within 2 person-days. (H,M)

Risks:

- There is no mechanism to detect malicious plug-ins (intentional or otherwise). Could corrupt data, erase data, compromise information, or otherwise crash the Palm.

- There are a variety of security issues. Some are hard to tackle, some are not so hard. Security seems to outside of the scope of the project.

Scenario #3. An application requires a plug-in. PAMD generates a list of compatible plug-ins. After a user selects the plug-in, PAMD loads the plug-in and transfers control to the plug in 3 seconds not including user selection time. (H,M)

Risks:

- PAMD interrogates every file in the registry every time a plug-in is required. If the list of plug-ins is very large (1000 plug-ins), this process will be very slow.

Tradeoff:

- Complexity for maximizing efficiency. There has to be two plug-in discovery methods. For versions below 3.5, system add/delete events can’t be captured. So every time a registry is queried the PAMD has to be scan the whole system for new/deleted plug-ins, and each new plug-in will have to be queried for the data type to update the registry. On OS versions 3.5 and greater, add/events events are sent and the registry can update itself.

Non-Risk:

- A formal registry may not provide immediate benefits (versions below 3.5) However it does provide an opportunity to check/scrub/certify new plug-ins in the future. It also provides a significant performance increase. The ability to refresh the registry is a plus.

Scenario #4. A user tries to execute a deleted plug-in from an outdated plug-in list. The error is handled gracefully by PAMD by notifying the user and sends an error to the application. (M,H)

Risks:

- There is nothing that prevents the replacement of plug-ins with identical names and different functionality (consider Len’s secret number).

Tradeoff:

- Robustness at the cost of Performance: Applications have to check with PAMD and the registry that the plug-in exists prior to calling the plug-in. This is slower, but if the application called a plug-in that was deleted, the system could crash.

Scenario #5. A user has a Palm with OS version 4.0 and attempts to beam PAMD to another user with a Palm with OS version 3.1. PAMD works the same way on both systems. (H,H)

Risks:

- If a plug-in written on Palm OS version 4.X and is loaded and used on a Palm OS version 3.1, it will cause the 3.1 system to crash.

Sensitivities:

- PAMD is currently dependent upon and sensitive to changes in the Palm OS event model, shared memory model, and memory protection model.

Scenario #6. A user has a Palm with OS version 4.0 and attempts to beam PAMD to another user with a Sony with OS version 3.1. PAMD works the same way on both systems. (H,H)

Risks:

- Its unknown what would happen to the PAMD control panel display if the screen resolution would change.

- There is no reliable way to interrogate a plug-in to find out what OS/HW versions it can safely run on. In the worst case the system will crash.

Scenario #7. Assume that “phone book” and “email” are separate applications on the Palm. A user wants to send email to a person in the phone book application. PAMD allows the user to select the person from the phone book application and PAMD transparently passes the email address and control from the phone book to the email application. (H,M)

Risks:

- Its unclear how control will be passed from phone book to email and then back to the phone book or if it should be implemented this way.

- Implementing this scenario would significantly change the design of PAMD (e.g. changes the meaning of what it means to be PAMD aware)

- Application to application communication and invocation hasn’t been considered in this design (actually was considered in the original design, but abandoned for a simpler model at the customer’s direction).

- It might be hard to implement this in some applications if they have to be teased apart to enter appropriate entry points in the code (i.e. jump from selecting an address directly to a new email message)

Tradeoff:

- More complexity for more flexible inter-application communication. To support this scenario, the definition of what it means to be PAMD aware need to be extended. PAMD aware applications would have to be more complex and converting applications to be PAMD aware would be more difficult.