Postmortem

General Comments

A list of issues both positive and negative that affected the project was drawn up. A formal development-team meeting was called to report on the development processes employed. This project wrap-up was used to discuss, document, and revise a list of development issues, and then produce a document that could later be referred to when developing a similar system or using similar technologies.

We walked through the following items in the project.

Online User Log-In

What did work?

• The user logging in through the use of the NetConnection.

• The return of the sessionUUID.

• The creation of the remote shared object by the FCS under the chat/general instance.

What should be done next time?

Maybe use the FCS to access the database directly or through ColdFusion to authenticate the user and then create the shared object in the chat/General instance without using the Client Flash App to send, receive, then send again. Saves network traffic.

Could have used CF advanced security instead of writing code to authenticate the user.

Invitations

What didn't work?

If the user logs out and then back in, the system doesn't recognize the requests for the new log-in.

What did work?

Invitations are stored in both the database and the shared object in the chat/General instance. This was due to the introduction of the FCS. The initial approach had been to query this data every time the server was polled. As the code had already been developed, the FCS evolution was to keep the current working code and be able to leverage off the new technology to deliver the invitation. The storage of the invitations is both volatile and nonvolatile.

What should be done next time?

If the user logs out and then back in, and the system doesn't recognize the outstanding requests, maybe the user should have a permanent UUID rather than being given a new UUID on log-in

Real-Time Messaging

What didn't work?

Initially the project did not have the capability to deliver real-time messaging efficiently. The initial thought was to use the SetInterval function to refresh (poll) the server to receive any new messages, users, and invitations. This would have been a performance issue, as all client applications would be polling the server a determined number of times a minute. The scalability of the application would be in doubt. The FCS features allowed a new avenue that saved TSC the time it would have taken to develop a system that could not scale.

What did work?

The design documents were defined before the FCS technology was known or decided upon. This could have had a dramatic impact on the end product if the design documents could not have been used. By using the MVC TSC and segmenting the development, TSC had the advantage of being able to plug in a technology with not too much redevelopment. This technology was viewed as being able to accommodate the system's growth to video and audio streaming.

What would you do differently?

The first item on the agenda was "What would you do differently?" This promoted a lot of discussion, as the team's knowledge of the FCS, CFCs, and Flash MX had grown from the novice to the intermediate level in a few short months. In hindsight, there are always similar or innovative techniques that can deliver similar or better solutions. Most of the developers discussed their own approaches and how they would now approach the same problem. The server-side shared object was the first issue discussed. The next item on the table was the approach that should be used to determine when to implement a persistent or a nonpersistent server-side shared object. The request process and security were also discussed, as well as development of an in-house Flash MX function that mimics the CFMX <cfdump> tag.

What worked generally?

Developing the general individual chat UI as a separate system that could be reused with a different management interface if needed.

Shared objects were the application's savior. Without this technology it would have been a clunky, bandwidth- and CPU-hungry system.

Having the controller under the au.com.tatam.chat package allows for the expansion of a new client-side UI. Both the old and future UIs could use this controller. The new system could pass an additional parameter such as version and then use conditional logic to deliver the required functionality.

 <cfcomponentname="Controller"hint="controlstheChat Center"> <cffunctionname="setNewSession"access="remote">  <cfifparameterexist(ARGUMENTS.Version)>  <cfifARGUMENTS.VersionEQ"2">   <cfinvoke component="au.com.tatam.chat.session.SessionV2"   method="setNewSession"   argumentCollection="#ARGUMENTS#"   returnVariable="result"/>  </cfif>  <cfelse>   <cfinvokecomponent="au.com.tatam.chat.session.Session"   method="setNewSession"   argumentCollection="#ARGUMENTS#"   returnVariable="result"/>  </cfif>  <cfreturnresult/> </cffunction> <cffunctionname="CreateChatRequest"access="remote"> <cfifparameterexist(ARGUMENTS.Version)>  <cfifARGUMENTS.VersionEQ"2">  </cfif>  <cfelse> <cfinvokecomponent="au.com.tatam.chat.dialog.Request"    method="CreateChatRequest"    argumentCollection="#ARGUMENTS#"    returnVariable="result"/> </cfif> <cfreturnresult/> </cffunction> </cfcomponent> 

Once the notes were typed up, the document was circulated to all TSC developers (not just the ones developing the chat system). It was also stored in TSC's document-management system to be available to all staff under an easy-to-find classification.

Client Meeting

The client meeting was organized to extract any post-delivery issues. As the email acknowledged, there were a number of agenda items to discuss. Since the client was satisfied with the end product, the meeting had a positive atmosphere that fostered the mining of constructive criticism. At the end of the meeting, it appeared the major weakness was the user-interface approach, and the major strength was the use of the latest technology to implement the system.