Masalah Teknis Hybrid Blackberry

izin copas lagi gan dari blog tetangga .. langsung cekidot aja deh biar ga lama-lama … aku copas tulisan ini dari … http://blog.compactbyte.com/2010/11/19/masalah-teknis-hybrid-blackberry/

ayo langsung di baca aja ya ..

 

Tulisan saya sebelumnya (OS Hybrid Blackberry: Usaha yang sia-sia) mengundang banyak respon dari berbagai pihak. Sayangnya responnya bersifat emosional dan tidak membangun, tidak bersifat teknis. Nah sekarang saya akan membahas beberapa hal teknis lanjutan mengenai hybrid. Saya sebutkan di artikel saya bahwa hybrid bisa saja berhasil kalau kita *tahu* apa yang kita campurkan. Yang menjadi masalah, dan menjadi kritik utama saya adalah: kebanyakan hybrid itu ngasal, jadi kemungkinan berhasilnya kecil (dan andaikan berhasil, kemungkinan membuat bug lain lagi). Saya juga mengkritik bahwa menyebarkan hybrid itu sifatnya illegal (kalimat saya adalah ‘sebenarnya penyebaran OS hybrid adalah sesuatu yang illegal’). Mungkin ada yang salah paham: membuat hybrid itu legal (silakan Anda campur-campur sendiri file yang sudah Anda download sendiri). Yang saya kritik adalah penyebarannya atau istilah legalnya redistribution.

Di artikel ini saya akan menuliskan bagaimana caranya supaya hybrid menjadi tidak ‘ngasal’ dan bagaimana mengatasi masalah redistribution sehingga bisa tetap membuat hybrid yang legal. Saya akan mulai dulu dengan masalah teknis, lalu akan saya teruskan dengan masalah legalitas redistribusi modul. Perlu ditegaskan: Saya tetap tidak berniat membuat hybrid. Tulisan ini hanya untuk melengkapi tulisan saya sebelumnya kalau Anda masih ingin membuat hybrid.

Masalah pertama yang dimiliki para hybrider adalah: kekurangtahuan masalah teknis. Ini dari hal dasar mengenai pemrograman: apa itu modul, apa itu kelas, apa itu inteface, dsb sampai ke masalah teknis jaringan, misalnya apa itu LDAP atau DNS resolver. Tanpa mengetahui itu semua, kita masih bisa terus berjalan meski akan sering terantuk batu, tapi jika tahu maka akan lebih baik.

Hal mendasar yang harus diketahui oleh para hybrider adalah: modul apa yang harus diganti. Kadang nama modul sangat mencerminkan isinya, misalnya net_rim_bb_twitter itu isinya adalah aplikasi twitter. Masalahnya adalah ada banyak nama yang tidak jelas, misalnya net_rim_bb_elt atau net_rim_se13nettable. Ada juga modul utama yang namanya jelas, seperti net_rim_bb_addressbook_app tapi modul pendukungnya kurang jelas, misalnya net_rim_bb_addressbook_gal.

Hal teknis pertama yang bisa dilakukan oleh para hybrider adalah: mendokumentasikan fungsi setiap modul. Hal ini jelas gunanya: supaya tidak ngawur mencampur modul. Misalnya saya pernah melihat di salah satu hybrid: ada masalah web browser, lalu dia mencoba mengganti modul net_rim_bb_ldap_browser dengan harapan browsing akan lebih baik, hal tersebut ngawur, karena meski ada kata-kata “browser”-nya, modul tersebut tidak ada hubungannya dengan web browsing. Modul tersebut berhubungan dengan LDAP suatu protokol layanan direktori. Kata-kata ‘browser’ di situ tidak berhubungan dengan web browser. Bahkan bagi pengguna awam yang tidak terhubung dengan enterprise, perubahan tersebut tidak berpengaruh sama sekali terhadap apapun di handsetnya (sia-sia, karena modul ini dipakai oleh modul secure email/pgp).

 

Saya sudah memulai dokumentasi mengenai deskripsi modul, tapi karena keterbatasan waktu, hasilnya baru sedikit. Ini bisa dilihat di http://yohan.es/blackberry/modules/. Dokumentasi ini boleh dianggap masih versi 0.1. Tujuan dokumentasi saya sebenarnya bukan untuk membuat hybrid. Itu awalnya dari catatan pribadi ketika melakukan reverse engineering, tapi ternyata berguna juga ketika shrinking (saya bisa memilih dengan mudah modul mana yang ingin saya hapus, karena saya melakukan shrinking manual dengan program bjavaloader di Linux). Karena informasi ini mungkin berguna bagi orang lain, maka sekalian saya share.

Untuk bisa menjadi referensi yang berguna, masih ada banyak hal yang harus dilengkapi dari dokumentasi saat ini yaitu:

1. Lengkapi semua modul, saat ini baru sebagian modul yang tercantum
2. Tambahkan informasi mengenai ketergantungan antar modul. Misalnya net_rim_bb_addressbook_gal dibutuhkan oleh address book untuk Global Address List, tapi tidak bisa kita hapus karena merupakan komponen penting bagi address book. Catatan: ini sudah saya tambahkan, menggunakan skrip otomatis dari output disassembler (ini juga bisa didapat dengan javaloader dir -d).
3. Sebaiknya ada pemetaan terhadap fungsionalitas pengguna dan nama modul. Misalnya: fungsi SMS dipengaruhi oleh modul mana saja. Hal ini supaya jika masalah di versi terbaru hanya di masalah SMS, jangan mengubah hal-hal yang tidak berhubungan sama sekali.
4. Tambahkan informasi mengenai versi modul. Misalnya modul versi 100 dan 200 ternyata tidak berubah, atau “modul X versi 100″ lebih cepat dari “modul X versi 200″. Ini supaya tidak ngawur, mengganti modul X versi 100 dengan versi 200 padahal isinya masih sama persis.
5. Tambahkan deskripsi yang lebih lengkap mengenai cara kerja modul. Misalnya: aplikasi kamera tidak memakai native API sama sekali. Jadi menukar-nukar modul kamera tidak akan memperbaiki gambar.

Dokumentasi ini akan terus saya perbaiki jika saya ada waktu luang sambil saya menyelami internal Blackberry, jadi saya harapkan orang-orang tidak langsung mulai mengkritik “masih minim sekali dokumentasinya”. Kalau memang Anda bisa membuat yang lebih baik, silakan saja memulai. Nah untuk para ‘hybrid master’ yang menganggap saya ‘sombong’, silakan buktikan kerendahhatian Anda dengan berbagi ilmu pada sesama mengenai pengetahuan Anda mengenai modul-modul Blackberry. Buat Anda yang banyak berkomentar, mungkin sebaiknya berhentilah berkomentar, dan mulailah berkarya.

Perhatikan bahwa dokumentasi memegang peranan penting di sini. Gregor Mendel tidak tahu mengenai struktur DNA (analoginya: dia tidak tahu internal program), tapi dia melakukan pencatatan teliti dari sudut pandang matanya tanpa peralatan modern (ini analoginya: tidak tahu internal program, hanya memperhatikan masalah modul dari sisi pengguna). Kontribusi Mendel sangat besar karena dia membuat pengamatan yang sangat tajam. Jadi meski kurang mengenal internal program, sebenarnya para hybrider masih bisa berlaku ilmiah jika mau melakukan pencatatan yang baik dan membagikan hasilnya pada orang lain.

Tidak ada alasan untuk tidak mencatat modul-modul yang dicampur berikut dengan mengapa Anda mencampur dan apa deskripsinya (kecuali Anda memang tidak punya alasan, dan ngawur saja mencampur modul). Jika pengamatan Anda akurat, ilmunya akan sangat berguna bagi orang lain. Misalnya ada pengguna bermasalah hanya di bagian SMS, dia tidak perlu mendownload hybrid baru, jika tahu versi mana yang bagus (misalnya dia cukup mengambil versi lama yang dia miliki).

Selain membuat dokumentasi, saya juga menyarankan para hybrider untuk belajar hal-hal lain selain mencampur modul. Misalnya belajar mengenai jaringan dan aplikasi enterprise. Saya berikan contoh lain yang saya temukan yang menurut saya “lucu”: ada hybrider yang mencampur modul net_rim_bb_dnslookup_app dengan harapan bisa membuat browsing lebih cepat. Logika mereka fungsi lookup DNS yang baru bisa lebih baik.

Nah masalahnya adalah: fungsi lookup DNS dilakukan oleh library resolver, bukan oleh aplikasi. Tepatnya ini diimplementasikan di net.rim.device.cldc.io.dns.DNSResolverIPv4 dalam modul net_rim_cldc. Program DNS lookup hanya akan dijalankan jika Anda memilih “Options” “Mobile Network”, lalu menekan tombol menu “Tool”, lalu memilih “DNS Lookup” (jadi jika Anda tidak pernah memilih menu itu, maka perubahan itu sia-sia saja). Analoginya dengan desktop, Anda tidak akan membuat DNS lookup menjadi lebih cepat dengan mengganti program dig atau nslookup karena program itu tidak dipakai oleh browser (browser akan menggunakan langsung library resolver).

Mengenai masalah legalitas redistribusi, ada solusinya, meski mungkin kurang nyaman bagi sebagian orang. Ada beberapa program open source yang menghadapi masalah redistribusi, salah satunya adalah corefonts. Proyek ini berusaha ingin memberikan akses font Microsoft kepada pengguna Linux. Mengapa ini diperlukan? Ada beberapa alasan: meski ada banyak font di Linux, font-nya kadang tampil aneh di website tertentu yang berfokus pada Microsoft, kemudian ada beberapa program yang dijalankan di Wine yang akan aneh tampilannya jika diberi font lain. Selain itu beberapa dokumen dalam format Ms Word juga bisa berubah layoutnya jika diberi font lain.

Masalahnya Microsoft tidak mengijinkan redistribusi, artinya: Anda boleh download font Anda sendiri dari Microsoft, tapi Anda tidak boleh menyebarkan yang Anda download ke orang lain. Bagimana proyek corefonts mengatasi hal itu? Proyek tersebut hanya menyediakan skrip. Jadi ketika Anda mendownload dari website corefonts, Anda sama sekali tidak diberi file yang hak ciptanya ada di Microsoft. Anda hanya mendownload sebuah skrip kecil saja. Ketika dijalankan di komputer Anda, skrip itu akan otomatis mendownload dari website Microsoft (atau pihak lain yang diberi hak redistribusi oleh Microsoft). Jadi pengguna di rumah yang mendownload langsung font dari Microsoft (legal), bukan disebarkan oleh pengembang corefonts. Skrip kemudian secara otomatis mengekstrak font dari file .exe (dengan cabextract), lalu memasangnya di direktori yang sesuai.

Apa hubungannya hal tersebut dengan solusi hybrid yang legal? Masalah redistribusi bisa diatasi dengan cara yang sama. Ini merepotkan pengguna hybrid di awal, tapi bisa menghemat di akhir. Begini detailnya: Jika hybrid adalah campuran versi 100, 200, dan 300, maka kita bisa meminta pengguna mendownload OS resmi versi 100, 200, dan 300, lalu kita berikan satu program (atau skrip kecil), yang akan mencampur modul-modul tersebut sesuai keinginan kita. Di awal, ini akan sangat merepotkan, karena user perlu mendownload beberapa OS resmi yang besar. Tapi ketika hybrid baru dirilis (dengan kombinasi baru, tapi tidak memakai modul OS baru), maka pengguna cukup mendownload file yang kecil saja (hanya skrip untuk mencampur saja, mungkin hanya puluhan atau ratusan kilobyte).

Jika semua orang setuju cara tersebut, maka pada akan ada penghematan besar dalam bandwidth total. Misalnya ada 50 pembuat hybrid yang masing-masing membuat 20 versi, semuanya berdasarkan versi 100,200, dan 300. Maka pengguna cukup mendownload sekali saja OS resmi versi 100, 200 dan 300, dan hanya perlu mendownload 50 x 20 = 1000 skrip hybrid, yang ukurannya sangat kecil (dibandingkan hybrid sekarang yang satunya berukuran puluhan hingga ratusan mega).

Demikian pembahasan teknis kali ini. Semoga responnya lebih baik dari artikel sebelumnya. Pada artikel sebelumnya, saya tadinya berharap ada hybrider yang membahas secara teknis seperti tulisan saya ini (bagaimana membuat hybrid dengan cara yang lebih ilmiah), dan sekarang dengan tulisan ini, saya berharap ada hybrider yang membuat hybrid secara ilmiah dan lebih terbuka untuk membagikan metodenya ke masyarakat umum. Jika memang Anda tahu yang Anda lakukan (tidak ngasal seperti “tuduhan” saya di artikel sebelumnya), tentunya Anda tidak malu membagi “resep” Anda untuk masyarakat. Tentunya Anda sombong sekali jika merasa punya ilmu, tapi tidak mau membagikannya kepada orang lain.

Catatan Tambahan: Di beberapa negara, reverse engineering merupakan hal yang illegal dan di berbagai tempat ada batasan legal dalam reverse engineering. Saya sudah mempelajari legalitas mengenai ini, dan menurut saya yang saya lakukan masih dalam batas legal (saya tidak menerbitkan informasi yang sangat detail, tidak membuat competing product, dsb). Lihat juga proyek open source ReactOS atau Wine yang melakukan reverse engineering secara legal.

Supaya tidak banyak comment sampah seperti sebelumnya, comment yang gak berguna dan gak nyambung (secara logika) akan saya hapus. Silakan kalau mau ngejunk comment bisa dilakukan di forum lain (sama seperti posting sebelumnya yang dibahas puluhan halaman junk di forum lain).