1 / 17

User Interface; Graphical User Interface;Jabber XMPP-Core

User Interface; Graphical User Interface;Jabber XMPP-Core. Communicating between two presence-aware entities. XML Stream Starts with <stream> Ends with </stream> Stream is unidirectional; but two streams allowed over one TCP connection initial stream and response stream XML Stanza

amora
Télécharger la présentation

User Interface; Graphical User Interface;Jabber XMPP-Core

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. User Interface; Graphical User Interface;Jabber XMPP-Core

  2. Communicating between two presence-aware entities • XML Stream • Starts with <stream> • Ends with </stream> • Stream is unidirectional; but two streams allowed over one TCP connection • initial stream and response stream • XML Stanza • the stuff (packets) of the stream • presence, message, iq are the only upper-level types

  3. A basic session C: <?xml version='1.0'?> <stream:stream to='example.com' xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' version='1.0'> S: <?xml version='1.0'?> <stream:stream from='example.com' id='someid' xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' version='1.0'> ... encryption, authentication, and resource binding ... C: <message from='juliet@example.com' to='romeo@example.net' xml:lang='en'> C: <body>Art thou not Romeo, and a Montague?</body> C: </message> S: <message from='romeo@example.net' to='juliet@example.com' xml:lang='en'> S: <body>Neither, fair saint, if either thee dislike.</body> S: </message> C: </stream:stream> S: </stream:stream>

  4. A session gone bad C: <?xml version='1.0'?> <stream:stream to='example.com' xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' version='1.0'> S: <?xml version='1.0'?> <stream:stream from='example.com' id='someid' xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' version='1.0'> ... encryption, authentication, and resource binding ... C: <message xml:lang='en'> <body>Bad XML, no closing body tag! </message> S: <stream:error> <xml-not-well-formed xmlns='urn:ietf:params:xml:ns:xmpp-streams'/> </stream:error> S: </stream:stream>

  5. Motivating GUI via IM

  6. Email, Instant messages, chat • Email: send message based on name • must know name, but can guess it. • IM: can only send message to buddy • can have both sides agree to be buddies. • Chat: can only send message to “room” • must connect to “room” to get messages Asynchronous like “computation” Semi-synchronous like “interactive” Semi-synchronous like “parallelism”

  7. Big Idea: Abstraction • “Any problem in computer programming can be solved by adding a level of abstraction” • “Performance can be improved in programs by removing a level of abstraction” • Indirection used to support abstraction

  8. Big Idea for IM: Indirection • “Publish and subscribe” • Publish “presence” with a server • Subscribe to relevant published entities • Once when registering and whenever logon • “Interact” • direct communication • (mediated) indirect communication

  9. Hard vs Soft State • Hard State: server knows buddy list • can send status of each buddy to requester • Soft State: client knows buddy list • can ask status of each buddy • But indirection always requires hard state

  10. Instant Messaging • Clients register with server • When client logs on, others subscribe • Client sends message to server, server forwards to recipient • can only send messages to registered/published recipients • Supported operations: • Register, Unregister, Logon, Logoff, Send/Rec, Add/Remove Buddy, etc.

  11. Many disconnected pieces • Client-Server protocol (messier than just this) • Client code • User Interface Code • Semantics of interaction • e.g. send only to published & subscribed entities

  12. User Interface • Want to disconnect application from user interface • Application should work independent of UI • Character display and keyboard or fancier • main difference was number of columns and lines • Graphical user interface • make big assumptions about h/w abilities • not really independent of GUI

  13. Evolution

  14. Separating events from handlers • Register handler for event • Two different types of events: • within application • within window system. • Events connect the two pieces but are developed separately.

  15. Separation of GUI description • Glade

  16. No semantic content • why bad? • no error correction

More Related