ejabberd: Erlang Jabber Daemon

Pada dasarnya server jabber merupakan software aplikasi sebagai bentuk implementasi core protokol jabber. Secara fungsional, software ini memiliki tiga peranan besar: (1) Mengkomunikasikan entitas satu dengan entitas lain, (2) Mengkomunikasikan satu server jabber dengan server jabber lainnya, (3) Mengkoordinasikan beragam komponen (XEP-0144) yang diasosiasikan dengan server jabber. Gambar berikut melihatkan ketiga fungsi dasar ini,

Pada umumnya server jabber didesain secara modular, dengan paket kode internal yang khusus sehingga dapat menangani fungsionalitasnya seperti registrasi, otentikasi, presence, contact list, mekanisme pesan yang berstatus delay dan lain sebagainya. Beberapa software server jabber akan banyak kita temukan sekarang ini. Namun berikut, saya paparkan sedikit mengenai software ejabberd yang memiliki penggunaan secara luas beberapa tahun terahir ini.

ejabberd memiliki kesesuaian implementasi yang ketat dengan standarisasi protokol jabber. Baik itu core jabber RFC 3920 maupun beberapa XEP standar yang dikoordinasikan oleh XSF. ejabberd memiliki antarmuka web yang dapat diterjemahkan ke dalam bahasa lain. Mendukung proses komputasi terdistribusi dengan menjalankan beberapa node yang saling terkoneksi, mendukung runtime upgrade dan menyediakan dukungan untuk virtual host. Terdapat beberapa alternatif sistem manajemen database yang dapat digunakan, seperti PostreSQL, MySQL dan ODBC. Mendukung otentikasi LDAP, SSL/TLS, dan SASL.

Salah satu alasan utama kenapa ejabberd banyak direkomendasikan adalah erlang. ejabberd ini dibuat dan berjalan diatas erlang platfom/OTP. Semua sifat yang melekat pada ejabberd, datangnya dari erlang/OTP ini. Diantaranya adalah cross-platform, fault-tolerant, clusterable dan modular. Erlang memang dibuat dan sangat cocok untuk aplikasi yang membutuhkan pengolahan sistem terdistribusi, soft real-time, sistem konkurensi dan juga non-stop.

ejabberd terdiri dari banyak modul yang dapat memberikan dukungan dan kemampuan tambahan seperti menyimpan pesan offline, menghubungkan dengan protokol IRC, informasi personal vCards user (menyimpan vCards di LDAP atau database ODBC yang kompatibel mungkin dengan modul lain). Selain itu, beberapa modul dapat memberikan dukungan untuk ekstensi protokol XMPP, seperti MUC, HTTP-polling, publish-subscribe, dan pengumpulan statistik via XMPP. Dimulai dengan versi 2.0.0, ejabberd mendukungan transfer dengan proxy65 yang memungkinkan entitas jaringan  Jabber/XMPP di belakang NAT untuk berbagi file melalui SOCKS5 proxy. ejabberd dapat berkomunikasi dengan server jabber lain serta juga jaringan diluar dengan jabber dengan menggunakan sebuah gateway. Dan berikut merupakan daftar lengkap extensions protokol jabber yang juga terimplementasi pada ejabberd. Beberapa diantaranya adalah extensions protokol yang masih experimental dan bahkan ada yang sudah “usang” tapi masih relevan untuk pengembangan aplikasi-aplikasi yang berjalan pada jaringan jabber.

[Link] Daftar extensions yang didukung oleh ejabberd

Yslow: Tool Optimasi Website

Yslow adalah sebuah tool buatan Yahoo! untuk keperluan optimasi website. Tool ini dapat mengetes dan mengukur kecepatan loading website. Dengan memakai beberapa aturan yang jelas, tool ini akan memberi grade dari keseluruhan optimasi setiap halaman website, A sampai F. Semakin tinggi grade yang didapat maka tentunya semakin baik. Yslow awalnya hanya tersedia di firefox, tapi kini para pengguna Chrome dapat juga menggunakannya sebagai add-ons. Setelah terinstall pada browser, tool ini akan tampak disebelah kanan atas dengan ikon seperti speedometer berwarna biru seperti pada gambar berikut:

Ikon Speedometer

Klik ikon tersebut dan akan muncul tampilan sederhana dari tool ini. Yang harus  Anda lakukan hanya menekan tombol Run Test, kemudian tool akan menganalisis dan mengukur kecepatan akses dari halaman website yang sekarang anda akses. Output dari analisanya, terbagi menjadi tiga tab, antara lain:

1. Grade

Tampilan Grade

Pada tab grade, nilai dari aturan-aturan digunakan untuk menilai optimasi halaman web. Nilai yang diberikan beragam mulai bernilai A sampai F, semakin banyak nilai A yang didapat, tentunya semakin baik. Jika terdapat aturan yang memiliki nilai F, maka berarti Yslow tidak menganalisa pada bagian itu. Disamping memberikan nilai pada tiap aturan, tool ini memberikan saran kepada developer apa yang harus dilakukan untuk meningkatkan nilai optimasi pada setiap aturan. Pada bagian atas tab ini, juga ada grade keseluruhan nilai optimasi Yslow, tampak pada gambar bahwa website bisakomputer.com memiliki keseluruhan optimasi C (79).

2. Components

Tampilan Component

Pada tab ini, dapat dilihat semua komponen beserta ukurannya dalam sekali load halaman website. Ada lima jenis komponen yang ditangkap yaitu HTML, file JavaScript, file CSS, file animasi/flash (dari histats), serta file gambar yang disetting dengan CSS. Dari sini developer bisa menganalisa komponen komponen mana saja yang membutuhkan penanganan lebih lanjut.  Pada gambar diatas, tampak bahwa pada halaman home bisakomputer.com memiliki jumlah ukuran keseluruhan komponen 614.5k.

3. Statistics

Tampilan Statistics

Pada tab terakhir, dapat dilihat perbandingan halaman website sebelum terjadi cache komponen web dengan setelah browser menyimpan komponen web pada cache browser. Ini artinya pada bagian ini dapat dilihat statistik perbandingan ukuran total load komponen saat pertama kali diakses dengan akses selanjutnya. Tampak pada gambar bahwa pertama kali halaman bisakomputer.com diakses (sebelum terjadi cache), memiliki HTTP Request sebanyak 71 dan totalnya sebesar 614.5k, sedangkan setelah terjadi cache oleh browser, jumlah HTTP Request nya tinggal sebanyak 6 dan ukurannya tinggal 59.2k.

Rules Yslow

Ada beberapa aturan yang terbagi menjadi 6 aspek (Content, Cookies, CSS, Javascript, Image, dan Server) digunakan Yslow untuk mengukur optimasi halaman website. Aturan-aturan ini adalah,

1. Make fewer HTTP requests

Sebagian besar response time website dihabiskan pada download komponen website seperti gambar, CSS, javascript dan lain-lain. Mengurangi komponen-komponen ini juga akan memperkecil jumlah HTTP Request yang dibutuhkan untuk meload sebuah halaman website. Mengurangi belum tentu dengan menghapus komponen, ada beberapa trik yang dapat kita lakukan untuk memperkecil jumlah HTTP Request dengan mengurangi jumlah komponen website, diantaranya,a. Menggabungkan komponen websiteb. Menggunakan CSS Spritec. Menggabungkan dua atau lebih image menjadi singgle image (Image map). Contoh seperti image navigation bar

2. Use a Content Delivery Network (CDN) 

CDN adalah jaringan server-server diseluruh belahan dunia yang berfungsi untuk menyampaikan konten kepada user yang mengakses website dari klien CDN. Memakai layanan ini, membuat konten web seperti akan di mirror di server cadangan yang terletak di berbagai negara. CDN akan secara otomatis merespon dengan server yang terdekat dengan visitor konten tersebut. Hal ini tentu saja akan mempercepat loading website ketika dibuka oleh user. Ada banyak penyedia untuk layanan ini, berbayar maupun yang gratis. Untuk yang berbayar contohnya adalah CDN Amazon, sedangkan yang gratis dapat menggunakan layanannya cloudflare.

3. Avoid empty src or href

Kebanyakan browser tidak mengabaikan tag yang memiliki attributsrc dan href kosong. Browser akan tetap melakukan request ke server.

4. Add Expires headers

Pada prinsipnya, browser akan men-cache beberapa HTTP Request untuk mempercepat loading web. Sedangkan web server akan menggunakan Expires headers dalam HTTP Response untuk memberitahukan browser berapa lama komponen dapat disimpan di cache browser.

5. Compress components with gzip

Mengkompresi dapat juga mengurangi ukuran paket HTTP Request atau HTTP Response. Sejak HTTP/1.1, web cient sudah mendukung kompresi HTTP Request. Web client mendefinisikan jenis kompresi apa saja yang dapat diterima pada header request-nya.

Accept-Encoding: gzip, deflate

Web server akan mengkompresi HTTP Response yang dapat diterima oleh client dengan melihat Accept-Encoding pada header request. Tapi pada umumnya GZIP merupakan jenis kompresi yang populer dan efektif untuk urusan ini. Hampir 90% internet browser mendukung kompresi ini. Web server apache dapat mengaktifkan module mod_gzip untuk hal ini.

6. Put CSS at top

Letakkan file-file style CSS pada bagian atas dokumen html. Ini bertujuan agar browser lebih cepat untuk merender halaman website. Hal ini akan sangat bermanfaat sekali ketika user memiliki akses koneksi lambat karena halaman website akan tampak secara progresif. Tapi ketika file CSS diletakkan dibagian bawah dokumen, beberapa browser seperti IE akan memblok proses rendering untuk mencegah gambar ulang halaman web jika terjadi perubahan.

7. Put JavaScript at bottom

File-file script seperti javascript akan lebih baik diletakkan dibagian bawah dokumen HTML. Ini untuk mencegah terganggunya proses rendering halaman web karena download file script.

8. Avoid CSS expressions

Yahoo menyarankan untuk tidak menggunakan expressions CSS. Hal ini karena bukan satu atau dua kali ekspresi ini dievaluasi ulang oleh engine css, tapi setiap kali scrollatau setiap kali cursor mouse berubah maka ekspresi ini dievaluasi ulang dan ini akan mengganggu performasi dari halaman web. Contoh ekspresi css adalah sebagai berikut.

background-color: expression( (new Date()).getHours()%2 ? "#B8D4FF" : "#F08A00" );

9. Make JavaScript and CSS external

Hindari meletakkan script atau style dalam dokumen html. Jadikan script dan style dalam file sendiri-sendiri. Hal ini akan bisa dicache oleh browser daripada diletakkan inline dalam dokumen html.

10. Reduce DNS lookups

Frekuensi lookups DNS ternyata juga dijadikan faktor tersendiri oleh yahoo. Ini berarti file-file komponen tidak disarankan tersebar di sembarang tempat atau hostname lain. Yahoo menyarankan agar sekali load halaman website, frekuensi tidak lebih dari 4 lookups.

11. Minify JavaScript and CSS

Minify javascript atau css dapat dilakukan dengan menghilangkan karakter yang tidak perlu seperti menghilangkan karakter spasi dan karakter newline. Ada banyak tool yang bisa digunakan untuk urusan ini diantaranya,

[Javascript] :

1. Packer
2. JSMin
3. Closure compiler
4. YUICompressor (bisa juga digunakan untuk CSS)
5. AjaxMin (bisa juga digunakan untuk CSS)

[CSS]

1. CSSTidy
2. Minify
3. YUICompressor (bisa juga digunakan untuk javascript)
4. AjaxMin (bisa juga digunakan untuk javascript)
5. CSSCompressor

12. Avoid URL redirects

Browser tidak akan merender apapun ketika dia mendapati kode status 301 atau 302 pada header response. Browser kemudian me-redirect halaman ke “Location” yang juga ada pada header.

HTTP/1.1 301 Moved Permanently

Location: http://example.com/newuri

Content-Type: text/html

YSlow menyarankan agar menghindari penggunaan redirect halaman. Hal ini hanya masalah pada user experience, user akan mendapat halaman kosong sampai browser me-request kembali ke “Location” pada header tersebut.

13. Remove duplicate JavaScript and CSS

Cek semua komponen-komponen web agar tidak terjadi duplikasi. Ini sering kali terjadi pada file script javascript seperti jquery.

14. Configure entity tags (Etags)

etag adalah salah satu mekanisme pada HTTP untuk validasi web cache. etag ini dibuat oleh server dan diletakkan di header.

Etag: “686897696a7c876b7e”

Saat browser melakukan permintaan selanjutnya, ETag dikirim kembali ke server melalui field If-none-match pada header.

If-None-Match: "686897696a7c876b7e"

Di server informasi ini akan dicocokkan dengan etag yang ada di server.Jika informasi di server tidak ada perubahan data, maka server hanya akan mengirimkan respon singkat pada header berupa 304 Not modified. Jika terdapat perubahan informasi, server akan mengirimkan respon secara lengkap beserta etag yang baru. Dengan pemanfaatan etag, respon akan lebih cepat pada halaman yang sering diakses oleh user karena tidak perlu mengunduh ulang seluruh respon.

15. Make AJAX cacheable

Tujuan dari aturan ini adalah mengurangi request ke server. Data bisa pertama kali didapatkan dari server, tapi kemudian disimpan di cache browser untuk keperluan request selanjutnya.

16. Use GET for AJAX requests

Yahoo menemukan bahwa penggunaan POST pada ajax request memiliki dua langkah proses, pertama mengirimkan header, kemudian baru mengirimkan data. Sedangkan untuk GET hanya mengirimkan satu paket data, melalui URL. Itulah mengapa penggunaan GET lebih disarankan daripada POST, tapi data yang dikirim lewat GET ini, tidak bisa lebih dari 2k karena panjang max URL yang diperbolehkan hanya 2k.

17. Reduce the number of DOM elements

Ini bertujuan agar struktur DOM yang anda buat pada dokumen html tidak terlalu komplek dan rumit.

18. Avoid HTTP 404 (Not Found) error

Cek semua komponen agar tidak mengembalikan kode status 404.

19. Reduce cookie size

Hapus beberapa data cookie yang sudah tidak digunakan lagi.

20. Avoid AlphaImageLoader filter

Filter alphaImageLoader akan memblok proses rendering dan menghentikan browser ketika sedang mendownload image.

21. Do not scale images in HTML

Hal ini bertujuan agar gambar yang di download browser tidak melebihi apa yang dibutuhkan. Akan lebih baik me-resize gambar di server. Ada banyak tool yang bisa digunakan untuk urusan ini, contohnya adalah timthumb.

22. Make favicon small and cacheable

Setiap halaman web diminta, satu komponen yang selalu ada adalah favicon. Pilih atau buat gambar favicon sekecil mungkin dan pastikan bahwa favicon dapat disimpan di cache browser.

23. Split Components Across Domains

Beberapa komponen seperti image harusnya diletakkan pada domain server yang berbeda. Contoh seperti dokumen html terletak pada domain example.com, sedangkan image terletak pada domain statik.example.com. Keuntungan dari split seperti ini adalah browser dapat men-download semua komponen secara paralel.

Yslow merupakan tool yang sangat powerful untuk mengetes kecepatan loading website. Dengan memiliki aturan-aturan optimasi yang jelas, tool ini dapat menuntun developer untuk meningkatkan website agar lebih optimal. Dan pastinya masih banyak aturan-aturan optimasi yang belum atau tidak digunakan dalam tool ini dalam hal optimasi sebuah website, jika anda memiliki aturan optimas lain diluar yang dibahas disini, anda dapat menuliskannya di halaman komentar. Mari berdiskusi.

*Artikel ini pernah dimuat pada situs bisakomputer.com tertanggal 5 Juli 2012

Model Group Chat XEP-0045

Pada tahun 1999, komunitas jabber telah membuat sebuah basis sistem text conferencing yaitu groupchat 1.0 (GC). Basis sistem ini merupakan minimal fitur untuk implementasi chat room. Groupchat 1.0 ini merupakan protokol yang memiliki kemiripan dengan protokol Internet Relay Chat (IRC). Sedangkan spesifikasi Multi-User Chat (XEP-0045) merupakan spesifikasi advanced features sebagai pengembangan dari groupchat 1.0. Terdapat banyak sekali fitur yang ditambahkan pada spesifikasi ini, seperti invitation, room moderation, pembagian tipe room, dan room discovery.

Secara umum spesifikasi tidak merubah basis sistem groupchat 1.0 (backwards-compatible), sehingga baseline functionality dari groupchat 1.0 ini masih dipakai oleh spesifikasi ini. Fungsionalitas groupchat 1.0 yang dimaksud adalah:

1. Setiap room memiliki identitas unik sebagai "room JID" yang memiliki format penulisan room@service, contohnya thewolfpack@conference.hangover.com. "thewolfpack" adalah nama room sedangkan conference.hangover.com adalah alamat service dari Multi-User Chat.
2. Setiap partisipator didalam room teridentitas sebagai "occupant JID" dengan format penulisan room@service/nickname, contoh thewolfpack@conference.hangover.com/alex. "alex" adalah room nickname dari user yang tergabung pada room.
3. User dapat masuk kedalam chat room (menjadi partisipator) dengan mengirim secara langsung sebuah presence kepada alamat room@service/nickname.
4. Partisipator dapat mengubah nicknamenya dengan mengirim informasi presence ke room@service/newnickname.
5. Sebuah message dalam multi-user chat memiliki tipe "groupchat" dan memiliki alamat room@service. Service kemudian akan mengirimkannya kepada seluruh partisipator.
6. Partisipator keluar dari room dengan mengirimkan presence tipe "unavailable" ke alamat room@service/nickname.

Sedangkan fitur tambahan yang ada pada spesifikasi XEP-0045 ini adalah sebagai berikut:

1. Native conversation logging.
2. Membolehkan user untuk request menjadi member pada private room.
3. Membolehkan partisipator untuk melihat occupant JID pada non-anonymous room.
4. Membolehkan moderator untuk melihat occupant JID pada semi-anonymous room.
5. Dapat mengatur hanya moderator saja yang dapat mengganti topik/subjek sebuah room.
6. Membolehkan moderator untuk mengeluarkan (kick) partisipator dan visitor pada room.
7. Membolehkan moderator untuk mengeluarkan dan mencabut ijin bicara pada moderated room.
8. Membolehkan administrator untuk memberi dan mencabut ijin sebagai moderator room.
9. Membolehkan administrator untuk mengeluarkan user dari room (ban) dan juga mengatur daftar ban user.
10. Membolehkan administrator untuk memberikan dan menolak membership privileges dan juga mengatur daftar member pada membe-only room.
11. Membolehkan owner untuk mengatur konfigurasi sebuah room sebagai contoh memberikan limit member.
12. Membolehkan owner untuk menunjuk owner lain.
13. Membolehkan owner untuk memberikan dan mencabut ijin sebagai administrator dan juga mengatur daftar administrator.
14. Membolehkan owner untuk menutup room.

Pada dokumen spesifikasi ini, disebutkan juga beberapa room type yang didefinisikan seperti:

1. public vs. hidden
2. persistent vs. temporary
3. password-protected vs. unsecured
4. members-only vs. open
5. moderated vs. unmoderated
6. non-anonymous vs. semi-anonymous

Beberapa spesifikasi ini saya ambil dari dokumen manual XEP-0045 yang dikeluarkan IETF. Rekan-rekan akan lebih baik membaca dokumen tersebut untuk mengetahui lebih detailnya. Spesifikasi ini begitu komplek bahkan untuk pembuatan aplikasi group chat, tapi memang pada dasarnya spesifikasi ini tidak dibuat hanya untuk pembuatan aplikasi itu. Kita bisa membandingkan model yang ditawarkan spesifikasi ini dengan model yang ada pada spesifikasi publish-subscribe yang ada pada XEP-0060. Dari kedua model yang ditawarkan ini, model mana yang lebih cocok dengan aplikasi yang hendak kita buat.

Tidak hanya pembuatan group chat saja, saya pernah menemukan sebuah aplikasi chess (catur) yang juga memanfaatkan spesifikasi MUC untuk urusan bisnis aplikasinya. Yang saya maksud ini seperti invite lawan untuk bermain, lawan menyetujui undangan untuk bermain, melihat semua daftar permainan yang sedang berlangsung (room) dan juga sampai pada mekanisme user viewer (bukan pemain) yang hanya masuk untuk menonton jalannya permainan. Game-game model seperti ini tentunya kita sudah banyak melihat, bahkan kita pernah juga memainkannya sekarang ini, seperti game poker dari zynga, poin blank (PB). Dan pada akhirnya kita bisa dengan mudah membuat aplikasi game yang serupa karena modelnya sudah ada dan terbentuk yaitu dengan model Multi-User Chat XEP-0045 ini.

Sebelum menyetujui untuk memilih spesifikasi ini, penting juga untuk mengetahui bahwa setiap pesan masuk pada room tidak-lah bersifat durable. Artinya adalah pesan masuk akan disampaikan, hanya pada user-user yang sedang join room sekarang. Penting juga mengetahui maksud kata “join” pada kalimat ini. Entitas/user harus memiliki status network available dan telah bergabung kedalam room, baru kemudian pesan masuk akan dapat dia terima, tapi jika kemudian koneksi terputus maka dia tidak akan mendapatkan lagi pesan sedang masuk sekarang ini. Baik tipe room publik maupun member-only memiliki mekanisme pesan seperti ini. Tidak ada mekanisme queue untuk pesan masuk agar pesan tersampaikan semua pada entitas yang sudah langganan ke group seperti yang ada pada protokol AMQP dan MQTT. Untuk beberapa permasalahan yang ada ini, MUC mendefinisikan Discussion History yang akan sangat membantu, tapi tentu saja cara ini merupakan trik untuk mengatasi permasalahan yang ada. Untuk alasan seperti ini jugalah, kita harus hati-hati dalam memilih protokol dengan spesifikasi Multi-User Chat ataukah protokol dengan model publish-subscribe seperti XEP-0060, AMQP, MQTT, Apache Kafka, dll. 

Module Pattern Javascript

Modularisasi kode javascript bisa dilakukan dengan teknik module pattern. Teknik ini diperkenalkan oleh Douglas Crockfold, orang sama yang memperkenalkan JSON sebagai data interchange format. Sebenarnya tujuan utama dari teknik ini adalah menghindari penggunaan variabel global secara berlebihan. Sedikit variabel global yang ada pada aplikasi, tentunya akan semakin meningkatkan performa dari aplikasi yang akan jalan pada browser.

Dalam pemrograman javascript, baik variabel dan fungsi bersifat global atau publik, tidak ada scope private dan protected layaknya bahasa pemrograman lain seperti C, php, java. Tapi bukannya tidak bisa, kita bisa memberikan efek yang sama(scope variable) dengan memanfaatkan anonymous function dan single global variable yang nantinya juga memiliki efek sama dengan namespace.

Anonymous Function

(function () {
...
}());

Kode diatas merupakan bentuk dari anonymous function, ditambah dengan operator parentheses atau '()' yg tujuan nya langsung meng-call anonymous function. Anonymous function merupakan bagian fundamental dari kode javascript, semua kode yang berada didalam fungsi merupakan kode tertutup(closure) yang tidak akan bisa diakses dari luar. Kode akan terlihat lebih bersih dan kekawatiran kode memiliki nama yang sama atau collisions objek/variabel akan menjadi lebih kecil.

Single Global Variable

var myApp = {}; // Definisi single global variable object
myApp.messageHello='Hello'; // Membuat variabel didalam objek
myApp.sayHello = function() { // Menciptakan objek method sayHello
console.log(myApp.messageHello); // Display properti objek di console
};
myApp.sayHello(); // Memanggil method objek

myApp merupakan single global variable yang mereferensikan sebuah objek. Efek dari teknik ini, variabel dan fungsi dalam objek akan aman dari modifikasi script lain diluar objek myApp dan pemborosan global variabel pun juga tidak akan terjadi.

Module Pattern

Dengan memahami anonymous function dan single global variable, kita bisa menentukan variabel-variabel mana yang bisa bersifat global dan mana yang cukup hanya diakses diwilayah fungsi/lokal saja. Bukan hanya itu, kode seperti ini dapat memiliki efek sama dengan saat kita bekerja dengan modul-modul kode yang independen. Berikut adalah contoh kode saat kita menggabungkan kedua teknik ini.

var MODULE = (function () {
var my = {},

privateVariable = 1;
function privateMethod() {
...
}

my.moduleProperty = 1;
my.moduleMethod = function () {
console.log('Private variable: '+privateVariable);
console.log('MODULE variable: '+my.moduleProperty);
};

return my;
}());
MODULE.moduleMethod();

MODULE adalah variabel global yang dibuat dengan anonymous function, dengan me-return objek my. Variabel yang berada langsung di bawah anonymous function memiliki sifat scope private sedangkan properti dan fungsi dari objek my, bisa diakses dari luar/publik, tentu saja dengan menyebutkan nama "modul" nya jika hendak mengaksesnya.

Hal ini sangat bagus, selain kode yang kita buat tampak seperti modular, ada begitu banyak bentuk pengembangan teknik ini yang tentunya akan sangat bermanfaat saat kita berada di pemrograman front-end seperti nested namespacing dan lazy loading code. Berikut adalah manfaat dari module pattern seperti yang disampaikan oleh Brian Cray:

1. Scalable. Modules are isolated pieces of code that when well designed.
2. Team-ready. Building a large-scale javascript application is simpler with the module pattern.
3. Localized. Anonymous wrappers automatically create a new “namespace” for the whole module.
4. Cross-instantiation private variables.
5. Extensible. Want to dynamically add additional methods to a module? No problem.
6. Deferrable. Another advantage of its isolation and containment is that you can inject it on demand without worrying about its impact on other modules.

eXtensible Jabber untuk Instant Messenger

Banyak orang telah bekerja diatas core protokol jabber. Beberapa diantaranya membuatnya menjadi sebuah standar extension yang dapat dipakai semua orang. Alasan kenapa protokol ini banyak sekali ekstensi yang berseliweran dibanding dengan protokol lain adalah sifatnya yang extensibe. Huruf X dari singkatan XMPP adalah kata eXtensible. Extensible merupakan inti utama yang pengen dibuat dengan protokol ini. Dengan spesifikasi core protokol yang sederhana dan sifatnya yang extensible, semua orang dapat bekerja bersama menciptakan beberapa extensions untuk tujuan integrasi dengan arsitektur sistem mereka. Dengan juga seperti ini, protokol jabber memiliki tingkat interoperabilitas yang besar terhadap banyak teknologi dan protokol lain diluar itu seperti TLS, SASL, SIP, OAuth, SOAP, AMQP, WebDav, Web Socket,  HTTP, dll.

Terdapat kurang lebih tiga ratus standar ekstensi yang didaftar dan dikelola oleh XSF. Beberapa diantaranya adalah ekstensi yang biasa kita temukan pada aplikasi instant messenger. Beberapa ekstensi ini sudah lama dibuat, tapi tetap saja masih relevan dan tetap dipakai oleh aplikasi messenger sekarang ini. 

1. XEP-0054 vCard User

vCard adalah sebuah standar yang digunakan secara luas untuk informasi personal user. Format vCard ini didefinisikan pada RFC 2426. Sedangkan extension ini adalah spesifikasi yang mendefinikan bagaimana menyimpan dan mengambil sebuah representasi XML vCard entitas/user dari server jabber. Penyimpanan dan pengambilan vCard dapat dilakukan dengan mengirim <iq/> tipe set (storage) atau get (retrieval) ke server entitas jabber. Aliran IQ memiliki child elemen <vCard/> dengan namespace 'vcard-temp'. <vCard/> elemen mengandung unsur-unsur vCard-XML yang didefinisikan oleh vCard-XML DTD.

<iq from='mustofa@uin-malang.ac.id/home' id='v1' type='get'>
 <vCard xmlns='vcard-temp' />
</iq>

Contoh ini digunakan untuk mengambil vCard pengguna (sender) dari server jabber. Untuk mengambil vCard dari entitas/user lain dilakukan dengan menambahkan atribut "to" pada <iq> paket. Contoh keluaran yang akan didapat oleh sender adalah sebagai berikut:

<iq id='v1' to='tri@mimicreative.net/home' type='result'>
<vCard xmlns='vcard-temp'>
<FN>Achmad Mustofa</FN>
<N>
<FAMILY></FAMILY>
<GIVEN>Mustofa</GIVEN>
<MIDDLE/>
</N>
<NICKNAME>Tofa</NICKNAME>
<URL>http://goo-code.blogspot.com</URL>
<BDAY>1988-02-24</BDAY>
<ORG>
<ORGNAME>Mimicreative</ORGNAME>
<ORGUNIT/>
</ORG>
<TITLE>CTO</TITLE>
<ROLE></ROLE>
<TEL><WORK/><VOICE/><NUMBER>087859584883</NUMBER></TEL>
<TEL><WORK/><FAX/><NUMBER/></TEL>
<TEL><WORK/><MSG/><NUMBER/></TEL>
<ADR>
<WORK/>
<EXTADD></EXTADD>
<STREET>Jl. Soekarno hatta 29</STREET>
<LOCALITY>Malang</LOCALITY>
<REGION>Jatim</REGION>
<PCODE> 80202 </PCODE>
<CTRY>Indonesia</CTRY>
</ADR>
<TEL> <HOME /> <VOICE /> <NUMBER>087859584883</NUMBER></TEL>
<TEL><HOME/><FAX/><NUMBER/></TEL>
<TEL><HOME/><MSG/><NUMBER/></TEL>
<ADR>
<HOME/>
<EXTADD/>
<STREET/>
<LOCALITY>Malang</LOCALITY>
<REGION>Jatim</REGION>
<PCODE> 80209 </PCODE>
<CTRY>Indonesia</CTRY>
</ADR>
<EMAIL><INTERNET/><PREF/><USERID>goo.code@gmail.com</USERID></EMAIL>
<JABBERID>mustofa@jabber.com</JABBERID>
<DESC>
More information about me is located on my
personal website: http:goo-code.blogspot.com
</DESC>
</vCard>
</iq>

Jika tidak terdapat vCard kontak user, maka keluaran yang akan didapat sender adalah stanza IQ tipe error dengan elemen child <item-not-found>.

<iq id='v1'
 to='mustofa@uin-malang.ac.id'
 type ='error'>
<vCard xmlns ='vcard-temp'/>
<error type ='cancel'>
 <item-not-found xmlns ='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</iq >

Entitas/user bisa saja tidak memberikan informasi apapun terkait dirinya. Untuk kasus seperti ini keluaran yang akan didapatkan sender adalah seperti berikut.

<iq id='v1'
 to='mustofa@uin-malang.ac.id'
 type ='result'>
<vCard xmlns ='vcard-temp'/>
<iq>

Mengambil vCard menggunakan stanza IQ-get seperti yang ditunjukkan pada xml stream diatas, sedangkan untuk mengedit informasi vCard disini kemudian menggunakan IQ-set, seperti yang ditunjukkan pada paket xml berikut ini.

<iq id='v2' type ='set'>
<vCard xmlns ='vcard-temp'>
<FN>Peter Saint - Andre </FN>
<N>
<FAMILY >Saint - Andre </FAMILY>
<GIVEN>Peter </GIVEN>
<MIDDLE/>
</N>
<NICKNAME >stpeter </NICKNAME>
<URL>http: // www . xmpp . org / xsf / people / stpeter . shtml </URL>
<BDAY>1966 -08 -06 </BDAY>
<ORG>
<ORGNAME>XMPP Standards Foundation </ORGNAME>
<ORGUNIT/>
</ORG>
<TITLE>Executive Director </TITLE>
<ROLE>Patron Saint </ROLE>
<TEL><WORK/><VOICE/><NUMBER>303 -308 -3282 </NUMBER></TEL>
<TEL><WORK/><FAX/><NUMBER/></TEL>
<TEL><WORK/><MSG/><NUMBER/></TEL>
<ADR>
<WORK/>
<EXTADD>Suite 600 </EXTADD>
<STREET>1899 Wynkoop Street </STREET>
<LOCALITY>Denver </LOCALITY>
<REGION>CO </REGION>
<PCODE>80202 </PCODE>
<CTRY>USA </CTRY>
</ADR>
<TEL><HOME/><VOICE/><NUMBER>303 -555 -1212 </NUMBER></TEL>
<TEL><HOME /><FAX /><NUMBER /></TEL>
<TEL><HOME /><MSG /><NUMBER /></TEL>
<ADR>
<HOME/>
<EXTADD />
<STREET />
<LOCALITY >Denver </LOCALITY>
<REGION >CO </REGION>
<PCODE >80209 </PCODE>
<CTRY>USA </CTRY>
</ADR>
<EMAIL><INTERNET/><PREF/><USERID> stpeter@jabber . org </ USERID ></EMAIL>
<JABBERID > stpeter@jabber . org </JABBERID>
<DESC>
Check out my blog at https: // stpeter .im/
</DESC>
</vCard>
</iq>

2. XEP-0184 Receipt Message

Sesuai dengan core protokol jabber, bahwa stanza message bersifat send and forget. Message akan terkirim dan tidak mengembalikan laporan apapun ke sender. Core jabber tidak menspesifikan laporan ke sender bahwa stanza message yang dia kirim telah diterima pada tujuan. Dengan extension ini memberikan sebuah mekanisme apakah sebuah message yang telah dikirim oleh entitas sender sudah sampai pada entitas tujuannya (delivered). Terdapat dua elemen yang didefinisikan pada spesifikasi ini, yang pertama adalah <request/> yang diikutsertakan pada setiap message entitas sender, kedua adalah <received/> yang dikirim oleh entitas receiver, menandakan sebagai ack bahwa message telah delivered.

<iq 
 from='mustofa@uin-malang.ac.id/kantor' 
 id='disco1' 
 to='himma@mimicreative.net/kantor' 
 type='result'>
 <query xmlns='http://jabber.org/protocol/disco#info'>
 ...
 <feature var='urn:xmpp:receipts'/>
 ...
 </query>
</iq>

Receipts message memiliki namespace "urn:xmpp:receipts" pada keluaran Service Discovery. Baik entitas sender maupun entitas receiver yang terhubung harus memiliki namespace ini. Service discovery ini merupakan sebuah mekanisme bagi setiap entitas untuk mengetahui service atau fitur apa saja baik yang didukung oleh server maupun setiap entitas user.

Contoh sebuah paket message dengan spesifikasi ini adalah sebagai berikut,

<message

 from = 'mustofa@uin-malang.ac.id/kantor'
 id = '0c7des'
 to='himma@mimicreative.net/kantor' >
 <body>Ngopi, nanti malem ditempat biasa.</body >
 <request xmlns='urn:xmpp:receipts' />
</message >

Sender harus memasukkan juga sebuah atribut id pada tiap message yang akan dia kirimkan. Tampak pada contoh diatas, id message tersebut angka random 0c7des. Untuk melakukan implementasi XEP-0184 adalah dengan menambahkan tag request pada paket message seperti yang tampak pada contoh diatas. Ketika entitas tujuan juga mengimplementasi spesifikasi ini, maka dia akan mengirimkan sebuah paket ack yang menandakan bahwa paket message telah diterimanya.

<message 
 from='himma@ mimicreative.net/kantor' 
 id='698' 
 to='mustofa@uin-maliki.ac.id/kantor>
 <received xmlns='urn:xmpp:receipts' id = '0c7des' />
</message>

3. XEP-0085 Chat State Notifications

Pada dasarnya ekstensi ini menghasilkan beberapa informasi yang dapat membantu partner/user dalam sebuah sesi conversation. Informasi yang dimaksud adalah ketika user meninggalkan halaman chat conversation, atau ketika user sedang melakukan typing, atau mungkin juga membatalkan/menghapus semua kata yang seharusnya dia kirimkan. Ada lima state chat yang didefinisikan, yaitu:

1. <active/> : Definisi bahwa user mendukung ekstensi ini dan siap berpartisipasi terhadap chat session. 
2. <inactive/> : Definisi bahwa user tidak lagi aktif berpartisipasi terhadap chat session.
3. <gone/> : Definisi bahwa user selesai melakukan session.
4. <composing/> : Definisi bahwa user sedang melakukan "typing".
5. <paused/> : Definisi bahwa user sebelumnya melakukan "typing" tapi kemudian berhenti (melakukannya).

<iq

 from='haqqi@tomatech.mobi/office'
 id='disco1'
 to='tri@thewolflabs.com'
 type='result'>
 <query xmlns='http://jabber.org/protocol/disco#info'>
 ...
 <feature var='http://jabber.org/protocol/chatstates'/>
 ...
 </query>
</iq>

Spesifikasi ini memiliki namespace http://jabber.org/protocol/chatstates pada keluaran Service Discovery. User maupun partner dalam sebuah sesi harus memiliki namespace ini. Hal ini dapat digunakan sebagai mekanisme cek dan ricek bahwa user entitas tujuan/lain juga mendukung extension ini.

Beberapa contoh sebuah sesi percakapan dengan Chat State Notifications adalah sebagai berikut,

<message
 from='haqqi@tomatech.mobi/office'
 to='tri@thewolflabs.com/kantor'
 type='chat'>
 <body>Howl, jadi kapan?</body>
 <active xmlns='http://jabber.org/protocol/chatstates'/>
</message>

Pada contoh, user haqqi@tomatech.mobi/office memulai sebuah percakapan dengan mengirimkan paket <message/> dengan state active kepada tri@thewolflabs.com/kantor. Jika partner percakapan yaitu tri@thewolflabs.com/kantor juga support terhadap spesifikasi ini, maka contoh reply yang akan didapat adalah sebagai berikut:

<message
 from = 'tri@thewolflabs.com'
 to = 'haqqi@tomatech.mobi/kantor'
 type='chat'>
 <body>Nanti malem yah #BraveYourSelf</body>
 <active xmlns='http://jabber.org/protocol/chatstates'/>
</message>

Karena kedua entitas mendukung chat state notifications, maka keduanya kemudian dapat memperoleh state informasi terhadap sesi percakapan yang mereka lakukan.

<message
 from = 'haqqi@tomatech.mobi/office'
 to='tri@thewolflabs.com/kantor'
 type='chat'>
 <composing xmlns='http://jabber.org/protocol/chatstates'/>
</message>

4. XEP-0256 Last Activity

Ekstensi ini mendefinisikan sebuah mekanisme untuk mengetahui kapan terakhir sebuah entitas user aktif (terkoneksi dan terautentikasi pada server). Spesifikasi ini memiliki namespace jabber:iq:last. Ketika user memulai sebuah sesi presence, maka paket berikut memberikan informasi bahwa kapan user tertentu terakhir online atau aktif (memiliki status mode away atau xa) pada jam dan waktu tertentu.

<presence from='haqqi@mimicreative.net'>
 <query xmlns='jabber:iq:last' seconds='86511'/>
</presence>

<presence from='himma@mimicreative.net'>
 <show>away</show>
 <query xmlns='jabber:iq:last' seconds='600'/>
</presence>

Pada contoh terdapat informasi yang memberitahukan bahwa user haqqi@mimicreative.net terakhir online pada 24 jam dan 111 detik yang lalu dan user himma@mimicreative.net aktif pada 10 menit yang lalu.

5. XEP-0203 Delayed Delivery

Spesifikasi ini menyediakan timestamp informasi mengenai store data atau pesan delay pada server. Ketika entitas tujuan belum available untuk bertukar pesan, pesan yang masuk akan disimpan pada server (delay). Begitu entitas tujuan available, semua pesan delay akan terkirim padanya. Dengan memakai ekstensi ini, pesan delay yang masuk pada entitas tujuan akan terdapat tag <delay/> yang memuat informasi kapan entitas sender mengirim paket message ini.

<message from='' to='' type='chat'>
 <body>Hello</body>
 <delay xmlns='urn:xmpp:delay' from='' stamp='2002-09-10 T23:08:25Z'>
 Offline Storage
 </delay>
</message>


Receiving a Message Sent While Offline

<presence from='' to=''>
 <status>anon!</status>
 <show>xa</show>
 <priority>1</priority>
 <delay xmlns='urn:xmpp:delay' from='' stamp='2002-09-10 T23:41:07Z'/>
</presence>


Receiving the Last Presence Update of Another Entity

<message from='' to='' type='groupchat'>
 <body>Hola</body>
 <delay xmlns='urn:xmpp:delay' from='' stamp='2002-09-10 T23:05:37Z'/>
</message>





Receiving Cached Messages from a Conference Room

Masih banyak ekstensi yang dapat dimanfaatkan dalam rangka pembuatan aplikasi instant messenger. Sebenarnya ada tiga ekstensi lagi yang pengen saya masukkan, tapi berhubung banyak sekali spesifikasi manual dari masing-masing ekstensi ini, maka akan saya pisah untuk artikel selanjutnya. Tiga ekstensi ini adalah Multi-User Chat (XEP-0045), Message Archiving (XEP-0136), dan Personal Eventing Point (XEP-0163). Dengan memahami beberapa ekstensi ini, saya yakin membuat aplikasi messenger yang berjalan pada jaringan jabber akan menjadi mudah banget. Protokol ini memang sederhana tapi komplit, saya sarankan pada rekan-rekan sebelum memutuskan untuk membuat komponen/plugin yang berjalan pada server jabber coba cari dulu ekstensi-ekstensi yang sudah berjalan dan dibuat. Selain memang untuk memangkas waktu untuk development, ekstensi-ekstensi ini terus diawasi/dikembangkan agar tetap relevan terhadap perkembangan teknologi.

Core Protokol Jabber: XML Stanza

Core protokol jabber didefinisikan pada RFC 3920. Pada dokumen ini, terdapat dua pokok bahasan yang dijelaskan, yaitu  XML Stream dan XML Stanza. Seperti yang diketahui semua paket data yang ditransmisikan pada jaringan ini memiliki format XML. XML Stream yang hampir memenuhi isi dokumen mengenai bahasan (1) penggunaan protokol keamanan TLS (Transport Layer Security) pada jaringan jabber, (2) otentikasi menggunakan metode SASL (Simple Authentication and Security Layer) dan juga (3) mekanisme untuk binding sebuah resource untuk client koneksi yang terbentuk (Resource Binding). Setelah itu bahasan pada dokumen RFC 3920 akan beralih pada XML Stanza. Stanza ini merupakan salah satu dari child elemen XML Stream, seperti yang ditunjukkan pada gambar bawah. Dan pada artikel ini saya coba tulis hanya perbagian XML Stanza saja, hal ini karena memang pada prakteknya kita akan cukup banyak berurusan dengan ini untuk membangun sebuah sistem aplikasi yang berjalan pada jaringan jabber.

XML Stream dan XML Stanza

Terdapat tiga jenis XML Stanza yang ditransmisikan, antara lain message, presence, dan info query atau lebih dikenal dengan IQ.  Jenis pertama (1) message, merupakan general paket jabber berisi informasi yang dikirim dari satu entitas ke entitas lainnya. Pengiriman paket ini bersifat fire and forget, artinya entitas pengirim tidak akan mendapatkan result dari paket message yang telah dia kirimkan. Selain itu juga message ini dikirimkan dari dan ke one-to-one entitas atau one-to-many. Jenis yang kedua adalah (2) presence, dikirimkan dengan tujuan availability kehadiran entitas yang terhubung dalam jaringan. Entitas dapat mengetahui status online atau offline dari setiap entitas lain karena adanya aliran data presence ini. Tidak seperti message, presence dikirimkan ke semua entitas (broadcast) yang sudah subscribe ke entitas tersebut. Terakhir, jenis yang ketiga adalah (3) IQ, digunakan untuk mekanisme request-response antar entitas dalam jaringan jabber. Mirip dengan metode GET dan POST pada protokol HTTP. Terdapat sebuah entitas yang mengirimkan request ke entitas lain, dan akan menerima response balasan dari entitas tersebut.

XMPP Server

1. Message

Jabber menggunakan stanza message untuk mengirim pesan. Pesan dapat dikirm antara jabber client dengan jabber server atau antara jabber server dengan server jabber yang lain. Stanza message sangat sederhana, Entitas sender mengirim stanza message ke entitas recepient. Secara default tidak ada acknowledge ketika recepient menerima stanza message. Jika pesan dikirim dan recepient dalam keadaan offline maka server berkewajiban menyimpan pesan tersebut dan mengirimkannya ketika recepient sudah dalam keadaan online/available. Proses seperti ini mengacu pada proses store and foward. Pada dasarnya format untuk stanza message adalah sebagai berikut :

Message Stanza

1. to="" from="" Mengidentifikasikan sender dan recepient. Format alamat jabber diatur dalam spesifikasi core jabber mengenai JID. Atribut ini diperlukan untuk semua paket stanza message.
2. id="" Digunakan identifier yang unik pada pesan. Client dapat menggunakan id untuk mengidentifikasikan pesan jika paket message mengalami error. Atribut ini bersifat opsional.
3. type="error" Mengindikasikan bahwa pesan adalah error message.
4. type="chat" Mengindikasikan bahwa pesan ditampilkan dalam sebuat line-by-line chat interface (one-to-one chat).
5. type="groupchat" Mengindikasikan bahwa pesan ditampilkan dalam room chat interface.

Stanza message mempunyai dua set subelemen (child element) didalamnya. Pertama adalah content atau payload paket (body elemen dan error elemen) dan kedua adalah subelemen yang merupakan informasi metadata dari paket message tersebut (x elemen).

<body><body>

Subelemen ini membungkus isi pesan (payload) yang akan dikirimkan. Subelemen ini hanya diperbolehkan ada satu kali pada setiap paket stanza message dan juga harus berupa plain-text.

<x xlmns="jabber:x:"></x>

Subelemen ini digunakan untuk mengirim perintah antar client atau sebagai mekanisme tambahan. Setiap kali elemen ini digunakan, namespaces (xmlns) harus didefinisikan. Sebuah pesan dapat memiliki banyak elemen <x> ini. Sebagai contoh namespaces untuk out-of-bond extension dapat digunakan untuk mengirim file antar aplikasi.

Subelemen ini disertakan ketika atribut type dari pesan di set error. Error yang sebenarnya didefinisikan oleh atribut dengan type="nnn" yang menunjukkan jenis dari error tersebut.

• 302 – redirect
• 400 – Bad Request
• 401 – Unauthorized
• 402 – Payment Reuired
• 407 – Registration Required
• 408 – Request Timeout
• 409 – Conflict
• 500 – Internal Sevrer Error

Isi subelemen error adalah penjelasan teks untuk spesifik error yang sedang terjadi. Sebagai contoh, bad request akan memiliki format penulisan sebagai berikut :

<error type="400">Bad Request</error>

Contoh paket stanza message yang valid dikirim ke entitas/user tujuan adalah sebagai berikut:

<message from='mustofa@uin-malang.ac.id/kampus' to='haqqi@tomatech.mobi'>
   <body>Howdy</body>
</message>

2. Presence

Stanza presence ini bertanggung jawab terhadap dua hal dibawah ini, yaitu :

1. Presence Update, menginformasikan pengguna lain status presence yang sedang kita digunakan.
2. Presence Subscription Management, mengijinkan pengguna untuk mendaftarkan update presence dari pengguna lain dan mengatur siapa saja yang berhak mengetahui status kehadirannya.

Dalam kedua peran tersebut server jabber bertindak sebagai penengah antara presence information generator dan presence recepients. Server tidak memiliki kewenangan untuk secara pasif mengatur rute dari paket presence namun secara aktif server berpartisipasi di dalam paket presence untuk memastikan operasi dilakukan dengan benar.

Presence update menggunakan  model pesan satu arah atau one-way message. Client mengirim stanza presence untuk memperbarui status kehadirannya kepada server, kemudian server meneruskan salinan dari paket tersebut kepada semua pihak yang terdaftar pada presence subscription list dari client pengirim. Subscription list tersebut dinamakan roster di dalam jabber, namun lebih umum dikenal dengan sebutan buddy list.

Entitas jabber dapat dapat meminta subscribe presence dari entitas/client lainnya. Proses subscribing tersebut adalah sebuah mekanisme/kesepakatan untuk mengetahui status kehadiran dari entitas yang satu dengan yang lain. Sebagai contoh, kita dapat meminta subscribe presence teman sehingga ketika teman tersebut available/online, kita akan mendapatkan paket kehadirannya, tapi tidak sebaliknya.

Beberapa atribut stanza presence diasosiasikan sama dengan stanza message, seperti atribut to dan from. Presence memiliki memiliki tipe atribut yang memiliki 7 state sebagai berikut:

1. unavailable : client tidak lama tersedia untuk berkomunikasi
2. subscribe: pengirim mengirimkan request untuk subscribe terhadap presence penerima
3. subscribed: pengirim yang telah diizinkan terhadap recipient untuk menerima presence mereka.
4. unsubscribe : subscription request yang telah ditolak atau subscription yang telah di cancel sebelumnya.
5. probe: request dari client yang presence saat ini
6. error: pesan kesalahan yang berlangsung berdasarkan pemrosesan atau menyediakan paket presence yang telah dikirim sebelumnya.

Server menggunakan probe presence packet untuk request spesifik entitas dari presence packet. Dalam hal ini entitas yang dimaksud adalah menentukan apakan entitas tersebut available atau unavailable. Entity Probe mengijinkan informasi presence untuk dikirimkan

Elemen request probe presence dikirim dengan menggunakan format dibawah ini

<presence type="probe">

Elemen-elemen dibawah ini digunakan di dalam elemen <presence>.

<status></status>

Elemen ini digunakan untuk menampilkan deskripsi status dari user yang dapat langsung dilihat oleh user lain. Misal, pengguna ingin menampilkan status yang menunjukkan deskripsi dari apa yang sedang ia lakukan, “i’m at lunch" atau "be back in 5 minutes"

<priority><priority>

Elemen ini memberi prioritas dari presence pada satu entitas pengguna. Misal mustofa@uin-malang.ac.id mungkin login dengan menggunakan multiple resources (home computer, work dan work computer). Elemen ini memberikan prioritas angka untuk setiap resources. Semua pesan dan komunikasi akan diarahkan kepada resources yang mempunyai nilai prioritas paling tinggi. Ketika prioritas resources paling tinggi tersebut menjadi unavailable, pesan dan komunikasi akan dikirim ke resources lainnya yang mempunyai nilai prioritas tertinggi kedua. Prioritas yang bernilai negatif menunjukkan bahwa resources tidak dapat digunakan untuk direct atau immediate contact.

Elemen ini menunjukkan bagaimana status kehadiran seorang user kepada entitas/user lain.

• show : menggambarkan status yang tersedia dari entities atau resource yang spesifik. show memiliki empat nilai yang digunakan :
• away : temporarily away
• chat : bebas untuk chat
• xa : extended away
• dnd : do not disturb
• status : merupakan deskripsi bahasa natural yang bersifat opsional yang mendeskripsikan status yang tersedia.
• priority : bilangan integer bukan negatif yang menampilkan level prioritas pada resource yang terkoneksi, dengan 0 sebagai prioritas terendah.
• error : deskripsi pesan kesalahan

Contoh stanza presence adalah sebagai berikut :

<presence from='juliet@capulet.com/balcony' to='romeo@montague.net/orchard'>
 <show>away</show>
 <status>be right back</status>
 <priority>0</priority>
</presence>

Presence Stanza

3. Info/Query

Meskipun secara garis besar trafik jabber terdiri dari message dan presence, sebagian besar pekerjaan implementasi arsitektur client-server adalah mengatur urusan administrasi dan manajemen. Pada protokol jabber tugas tersebut menggunakan  generic query protocol yang disebut IQ. Tipe atribut pada stanza info/query memiliki 4 nilai yang dapat digunakan,

1. get : informasi request
2. set : menyediakan data yang dibutuhkan
3. result : respon terhadap get dan set request yang sukses
4. error : kesalahan yang terjadi dalam pemrosesan dan layanan get dan set request

Di dalam setiap IQ, sebuah namaspaces mendefinisikan tipe dari query yang akan dilakukan. Namespaces didefinisikan di dalam elemen query seperti yang ditunjukkan dibawah ini.

<query xmlns="*"/>

Paket IQ

Sebagai contoh, client mengirim query-set dengan client authentication namespaces ke server untuk login.

<iq type="set" to="mustofa@uin-malang.ac.id">
 <query xmlns="jabber:iq:auth"></query>
</iq>

Format protokol IQ yang digunakan pada jabber dapat dirumuskan seperti yang ditunjukkan dibawah ini.

<iq
 type='set|get|result|error'
 to='handler_jid'
 from='originator_jid'
 id='unique'>
 <query xmlns='iq extension namespace'>
 <query_field1/>
 <query_field2/>
 </query>
</iq>

Stanza IQ sangat penting jika ingin membangun server berdasarkan kebijakan keamanan sistem yang harus dipenuhi oleh client. Jika keamanan client telah terpenuhi maka harus mendukung pula terhadap keamanan pada sisi server.

Tipe IQ