A key feature that I recently added to the collaboration API (about 10 days ago) is an offline messaging capability. If you are a user of yahoo messenger you know how this works, when you are offline users are able to still open an IM window and send a message that you can then read when you log back into the system. I wanted to perform something like this since I finished the main implementation of the collaboration API almost a year and a half ago but I pushed it back , now that I am near the end I realized the 3 days it would take to code it was well worth the potential benefit it would bring to the users (and indirectly to the company!)
The offline messaging allows each User to control who can send them offline messages, unlike the yahoo thick client in which I periodically receive spam messages from users who are not on my contacts list. In my implementation, a User has 4 options that other Users can be given with regard to offline messages:
In addition to these options a User has a stealth mode option for when they are online, this allows them to come online silently without notifying their contacts (or any Users browsing profiles) of their presence. If a User is in stealth mode, naturally they appear offline to the offline messaging code and thus are subject to receiving the offline messages while online. This gives them the discretion to do nothing, respond to the User by private message or email. The User Settings page displays the status of Users based on the above mentioned settings, I discovered that the logic was all screwy...the offline notification settings were mixed up and would indicate a User was online when he should have been indicated as offline, when online the display link allows sending a private message as opposed to an offline message even if offline messages are disabled (this was another pathology). After looking into the code I realized one thing quickly, I need to clean up a bit! The conditional statements were not aligned very well, I soon discovered the issue and fixed it. I noticed one aspect of symmetry observant designs that employ method polymorphism and combinations of hierarchical and compositional class relationships is that the savings on the class level can turn into some interesting conditional relationships. The use of simple integers as attribute fields in the classes saves a great deal of code in that the class ends up having many attributes but these various dimensions when put together in the client code inspire the creation of conditional statements to build the desired behavior. Case in point with regard to the problem mentioned above was that several attributes of the user object were conditionally tested to determine which of the links (offline message or private message or conference or eject...etc.) displayed on the settings page, this led to some clauses containing up to 3 sub conditions, though this results in rather imposing looking conditions at first...with proper condition design (making sure to take advantage of short circuiting) this leads to rapidly executing conditions tailored to exit at the rate of highest likelihood given the condition sub conditions.
All that said, I am still noticing a great deal of places for optimization of the code to squeeze it down to as few essential bits (characters) as possible. Since the client code in my framework runs mostly in jsp templates, squeezing down the bits directly aids performance over the distributed cluster in the long run and that directly reduces costs for operating the business...all great things.
Time to get back to the implementation...
The offline messaging allows each User to control who can send them offline messages, unlike the yahoo thick client in which I periodically receive spam messages from users who are not on my contacts list. In my implementation, a User has 4 options that other Users can be given with regard to offline messages:
- Offline messages disabled
- Contacts offline messages only, notification off
- Contacts offline messages only, notification on
- Any User offline messages, notification off
- Any User offline messages, notification on
In addition to these options a User has a stealth mode option for when they are online, this allows them to come online silently without notifying their contacts (or any Users browsing profiles) of their presence. If a User is in stealth mode, naturally they appear offline to the offline messaging code and thus are subject to receiving the offline messages while online. This gives them the discretion to do nothing, respond to the User by private message or email. The User Settings page displays the status of Users based on the above mentioned settings, I discovered that the logic was all screwy...the offline notification settings were mixed up and would indicate a User was online when he should have been indicated as offline, when online the display link allows sending a private message as opposed to an offline message even if offline messages are disabled (this was another pathology). After looking into the code I realized one thing quickly, I need to clean up a bit! The conditional statements were not aligned very well, I soon discovered the issue and fixed it. I noticed one aspect of symmetry observant designs that employ method polymorphism and combinations of hierarchical and compositional class relationships is that the savings on the class level can turn into some interesting conditional relationships. The use of simple integers as attribute fields in the classes saves a great deal of code in that the class ends up having many attributes but these various dimensions when put together in the client code inspire the creation of conditional statements to build the desired behavior. Case in point with regard to the problem mentioned above was that several attributes of the user object were conditionally tested to determine which of the links (offline message or private message or conference or eject...etc.) displayed on the settings page, this led to some clauses containing up to 3 sub conditions, though this results in rather imposing looking conditions at first...with proper condition design (making sure to take advantage of short circuiting) this leads to rapidly executing conditions tailored to exit at the rate of highest likelihood given the condition sub conditions.
All that said, I am still noticing a great deal of places for optimization of the code to squeeze it down to as few essential bits (characters) as possible. Since the client code in my framework runs mostly in jsp templates, squeezing down the bits directly aids performance over the distributed cluster in the long run and that directly reduces costs for operating the business...all great things.
Time to get back to the implementation...
Comments