1 / 15

Instant messenger group

Instant messenger group. Final product presentation. Product description.

nancyc
Télécharger la présentation

Instant messenger group

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Instant messenger group Final product presentation

  2. Product description • The Recorder keeps a record of messenger chat sessions that can be later referenced. The user can interact with the Recorder and specify actions to be taken with each new conversation. The Recorder has the following functionality: • Record conversation. • Filter (Stop) recording. • Default filter settings • Can be chosen before or during conversation. • Set database information.

  3. Project description • Geographically distributed software project • Sweden and Croatia (and Canada during x-mas) • 4 ppl total • Goal • Recorder application for instant messengers • One Recorder to rule them all • One Recorder to find them • One Recorder to bring them all, and in the network bind them. ;-)) • Is the goal fulfuilled? • Yes, at least partially…

  4. Communication • There is generally no casual communication about the project, therefore communication must be more planned • Presentations and lectures - Video conference system • Scheduled meetings - Video meetings (web cam) • Scheduled meetings - Chat • Other communication - E-mail

  5. Checkpoints for controlling that the project is on time! 7 checkpoints Project description Delayed because of startup issues Requirements def (internal) Design description Module test (internal) Delayed because of x-mas System test (internal) Delayed because of x-mas Project approval Milestones w. 46 w. 47 w. 48 w. 49 w. 50 w. 51 w. 52 w. 1 w. 2 w. 3 2004 2003

  6. Requirments • Build upon existing messenger tools. • Store chat sessions for later retrieval • Allow searches in a user-friendly user interface • Robust • non-intrusive • Honour privacy • Be secure • Designed for future integration in Web Project

  7. Design choices • To conform to the requirements we made some design choices: • Yahoo Messenger as first case study • Plug-in • Dynamic libraries (DLLs) • Dynamic binding • Tray-icon • Recorder filters • Weak Encryption • Serverside daemon for DB connection • SQL • JDBC interface towards the database

  8. Conformance to Requirements • Build upon existing messenger tools. • The recorder build on an architecture that build on plug-ins. The libraries attach them selves to the IM program, which make the architecture robust and IM independent. • Store chat sessions for later retrieval • Store on local HD if no connection is present. If a connection to the database isn’t possible or corrupt, the recorder will temporarily store messages to a local media. • Allow searches in a user-friendly user interface • Searches are possible in a user interface • Keywords, User, date • Robust • Works even if no connection to db is present, runs even if IM crashes The recorder program works independent of if the messenger hangs or shuts down.

  9. Conformance to Requirements • Non-intrusive • The recorder requires a minimum of user intervention.A tray-icon is present when the recorder is started. Implements easy-to-use filters. • Honour privacy • Filter options are present to honor the privacy by letting the user decidewhat sessions (conversations) should be stored. • Be secure • Encryption is implemented to avoid abuse and corruption of the stored data. This also enforces privacy since no-one can read or alter information stored locally. • Designed for future integration in Web Project • The database used in the project can easily be merged together with the database of the web-group.

  10. Technical difficulties - security firewall • The server that runs the database used a firewall, and we were permitted only to use one port for establishing a connection, further on, we weren’t allowed to establish a direct connection to the database, the DB only accepted tcp connections running from the localhost interface. • Solution • The only viable solution to this problem is making a local daemon that runs on the server and accepts tcp connections on a designated port and routes them to the dbms

  11. Technical difficulties - Redundancy in messages • What if both users decide to record the conversation? • Solution • The tables are created in such a manner so to support simultaneous recording of messages from both sides • adds to security – potential chat participators can establish a rule that only messages that were recorded twice – from both chat participators – count • Adds stability – if both chat partners record a single session, every message has more chance to be recorded if networking problems occur • Alternative solution • A lot of code to check if messages coincide.

  12. Technical difficulties - serverside processing – what language/tool to use for checking the received queries? • How is compatability between daemon and IM handled? • Solution • we incorporated the message processing in our connection deamon • Drawback - the program has lost on flexibility – the daemon accepts only messages of a predefined type from the IM. • Benefit - the daemon acts as a filter for the communication, other messages from the tcp can be discarded right away before involving the dbms • alt. solution • a procedural language (SPL), however, using a pure java daemon seemed to add to the general portability

  13. A few techincal details • Java support is required on the server side (JVM) • Java support is not required on the client side • Client is written in ANSI C and should be portable among all Win32 platforms • Databased support conforms to std. SQL

  14. Lessons from distributed work • The most interesting part of this course was getting to learn about some new cultures • The geographically distributed development was harder then usual development. • Teleconferencing lectures was a very interesting part of the course. • The cours wasn't confined to academic laboratory work, it was more comercial and realistic. • It was an exotic and very interesting course and we hope that it will be repeated in the next year(s) for the follow-up generations. • Management and meetings requires more planning. • The importance of communication is stressed in this course. • Since there is generally no casual communication about the project, group members have to be outgoing in their efforts, make an effort to understand the other parts of the project. • The course was a bit short to get the best out of it…

  15. Finally A good laughter prolongs your life I’ll probably live ’til 200 ;-)) Thanks for a great working and social (cultural) experiance

More Related