Trac is being migrated to new services! Issues can be found in our new YouTrack instance and WIKI pages can be found on our website.

Changes between Version 3 and Version 4 of DesignGuidelines


Ignore:
Timestamp:
Apr 28, 2007, 9:56:39 PM (17 years ago)
Author:
John Bailey
Comment:

PrPl? is not a wiki page

Legend:

Unmodified
Added
Removed
Modified
  • DesignGuidelines

    v3 v4  
    1111== Clean Layering ==
    1212
    13 In plain language, this means that the protocol-specific code goes in the protocol plugin (PrPl or prpl), and that libPurple exists, and is cleanly separated from the user interface.  There are practical implications to this.  While all of our code depends on glib, only the Pidgin specific parts depend on GTK+.  To implement, for example, file transfer, there are 3 steps.  First, the protocol(s) have to support it.  By themselves, however, the protocols can do nothing.  So the "core," libPurple, has to support it also (the second step).  We do not want massive amounts of very similar code in libPurple, so the implementation of file transfer at the libPurple level has to abstract away from how individual protocols handle it, so as to be able to use the same calls from all file transfer supporting protocols.  Last, but not least, before the user can actually send or receive a file, the UI (Pidgin, Finch or Adium) must support it.  These interfaces know nothing about the protocol, and have only limited contact with the core.  This helps to enforce the desire for uniformity explained above.  It also makes it easier for the only sort of duplication we encourage: many interfaces.  The core implementation cannot assume too much about what the UI will do, because the GTK+ UI (Pidgin) might need to handle a file transfer somewhat differently than the ncurses based UI (Finch).  Patches that voilate this layering will be rejected.  In practice, this means that there is more work involved to introduce a new class of functionality, say file transfer, white-boarding, voice, or video.  On the other hand, it means less work to implement any given class of functionality for a new protocol or for a new UI.
     13In plain language, this means that the protocol-specific code goes in the protocol plugin (!PrPl or prpl), and that libPurple exists, and is cleanly separated from the user interface.  There are practical implications to this.  While all of our code depends on glib, only the Pidgin specific parts depend on GTK+.  To implement, for example, file transfer, there are 3 steps.  First, the protocol(s) have to support it.  By themselves, however, the protocols can do nothing.  So the "core," libPurple, has to support it also (the second step).  We do not want massive amounts of very similar code in libPurple, so the implementation of file transfer at the libPurple level has to abstract away from how individual protocols handle it, so as to be able to use the same calls from all file transfer supporting protocols.  Last, but not least, before the user can actually send or receive a file, the UI (Pidgin, Finch or Adium) must support it.  These interfaces know nothing about the protocol, and have only limited contact with the core.  This helps to enforce the desire for uniformity explained above.  It also makes it easier for the only sort of duplication we encourage: many interfaces.  The core implementation cannot assume too much about what the UI will do, because the GTK+ UI (Pidgin) might need to handle a file transfer somewhat differently than the ncurses based UI (Finch).  Patches that voilate this layering will be rejected.  In practice, this means that there is more work involved to introduce a new class of functionality, say file transfer, white-boarding, voice, or video.  On the other hand, it means less work to implement any given class of functionality for a new protocol or for a new UI.
All information, including names and email addresses, entered onto this website or sent to mailing lists affiliated with this website will be public. Do not post confidential information, especially passwords!