Menu
▾
▴
scrollkeeper-devel
|
From: Rajkumar S. <raj...@wi...> - 2003-06-03 13:21:50
Attachments:
scrl-patch.diff
yelp-patch.diff
|
Hi, Pls. refer our earlier discussions - http://sourceforge.net/mailarchive/forum.php?thread_id=2043389&forum_id=4112. I have written the API as proposed and its details are: - I. Signature of the API: ----------------------- int scrollkeeper_find_omffile_count (int *install_num, int *upgrade_num, int *uninstall_num) II. Argument Details: -------------------- install_num - return location for the count of omf files that needs to be registered upgrade_num - return location for the count of omf files that needs to be upgraded uninstall_num - return location for the count of omf files that needs to be unregistered III. Version of scrollkeeper used: --------------------------------- 0.3.11 IV. New Files Added: ------------------- a) libs/scrollkeeper-api.h - File to export the API b) libs/scrollkeeper-api.c - File to accommodate the API c) libs/libscrollkeeper.pc.in - Data for package check macro, it will be used by the applications using this API to check for the required version of scrollkeeper installed and to link the scrollkeeper lib with the application. V. Files Altered: ---------------- a) configure.in - changes for creating the package check file libscrollkeeper.pc from libscrollkeeper.pc.in b) libs/Makefile.am - changes required for adding new files and installing scrollkeeper-api.h in the standard "include directory" c) scrollkeeper.h.in - changes to include functions that are used across by scrollkeeper-api.c and update.c d) cl/src/update.c - export the functions to libs/scrollkeeper-api.c to be in sync with the routines declared in scrollkeeper.h VI. Implementation and Usage: ---------------------------- The API is written by reusing the existing code for 'scrollkeeper-update' (i.e., cl/src/update.c). install_num: - Say we are installing a new component and its postinstall scripts failed to run 'scrollkeeper-update' after installing the omf files in standard path. Now, when the user launches the help browser he wouldn't be able to view the help for the newly installed component. The help browser could make use of "install_num" from the api to check if there are any unregistered omf files and if so it can notify the users saying: "Unregistered help documents have been detected for some applications. Help for these applications will not be available. Please contact your system administrator to run 'scrollkeeper-update'." uninstall_num: - On uninstallation, if a component failed to run 'scrollkeeper-update' after removing the <component>.omf file the corresponding link in the help browser will be inaccessible and the same can be notified to the users in advance by using "uninstall_num" from the API. upgrade_num: - Say the post install script fails to run 'scrollkeeper-update' after a component upgradation and the <identifier url=> in the omf is pointing to a new xml file. Since the scrollkeeper_docs/database wasn't updated the help browser would still look for the older <>.xml file and will fail to show the help. This can be notified to the users by the help browser using 'upgrade_num'. VII. Attachments: ---------------- a) scrl-patch.diff - Changes for implementing the API in scrollkeeper. b) yelp-patch.diff - Patch for gnome help browser as an example for the usage of this API. Pls. review the patch and give in your valuable comments. Thanks & Regards, Raj. |
|
From: Rajkumar S. <raj...@wi...> - 2003-06-17 11:47:35
|
Hi, Am aware that it would need some considerable time to review this patch, pls. treat this as a friendly reminder for the same!:) Thanks, Raj. Rajkumar Sivasamy wrote: > > Hi, > > Pls. refer our earlier discussions - > http://sourceforge.net/mailarchive/forum.php?thread_id=2043389&forum_id=4112. > > I have written the API as proposed and its details are: - > > I. Signature of the API: > ----------------------- > int scrollkeeper_find_omffile_count (int *install_num, int *upgrade_num, > int *uninstall_num) > > II. Argument Details: > -------------------- > install_num - return location for the count of omf files that needs to > be registered > upgrade_num - return location for the count of omf files that needs to > be upgraded > uninstall_num - return location for the count of omf files that needs to > be unregistered > > III. Version of scrollkeeper used: > --------------------------------- > 0.3.11 > > IV. New Files Added: > ------------------- > a) libs/scrollkeeper-api.h > - File to export the API > > b) libs/scrollkeeper-api.c > - File to accommodate the API > > c) libs/libscrollkeeper.pc.in > - Data for package check macro, it will be used by the applications > using this API to check for the required version of scrollkeeper > installed and to link the scrollkeeper lib with the application. > > V. Files Altered: > ---------------- > a) configure.in > - changes for creating the package check file libscrollkeeper.pc from > libscrollkeeper.pc.in > > b) libs/Makefile.am > - changes required for adding new files and installing > scrollkeeper-api.h in the standard "include directory" > > c) scrollkeeper.h.in > - changes to include functions that are used across by > scrollkeeper-api.c and update.c > > d) cl/src/update.c > - export the functions to libs/scrollkeeper-api.c to be in sync with > the routines declared in scrollkeeper.h > > VI. Implementation and Usage: > ---------------------------- > The API is written by reusing the existing code for > 'scrollkeeper-update' (i.e., cl/src/update.c). > > install_num: > - Say we are installing a new component and its postinstall scripts > failed to run 'scrollkeeper-update' after installing the omf files in > standard path. Now, when the user launches the help browser he wouldn't > be able to view the help for the newly installed component. The help > browser could make use of "install_num" from the api to check if there > are any unregistered omf files and if so it can notify the users saying: > > "Unregistered help documents have been detected for some applications. > Help for these applications will not be available. Please contact your > system administrator to run 'scrollkeeper-update'." > > uninstall_num: > - On uninstallation, if a component failed to run 'scrollkeeper-update' > after removing the <component>.omf file the corresponding link in the > help browser will be inaccessible and the same can be notified to the > users in advance by using "uninstall_num" from the API. > > upgrade_num: > - Say the post install script fails to run 'scrollkeeper-update' after a > component upgradation and the <identifier url=> in the omf is pointing > to a new xml file. Since the scrollkeeper_docs/database wasn't updated > the help browser would still look for the older <>.xml file and will > fail to show the help. This can be notified to the users by the help > browser using 'upgrade_num'. > > VII. Attachments: > ---------------- > a) scrl-patch.diff > - Changes for implementing the API in scrollkeeper. > > b) yelp-patch.diff > - Patch for gnome help browser as an example for the usage of this > API. > > Pls. review the patch and give in your valuable comments. > > Thanks & Regards, > Raj. |
|
From: Malcolm T. <ma...@co...> - 2003-06-19 03:20:56
|
Hi Raj, On Tue, 2003-06-17 at 21:55, Rajkumar Sivasamy wrote: > Am aware that it would need some considerable time to review this patch, > pls. treat this as a friendly reminder for the same!:) Nice of you to think that maybe somebody was just taking a long time to review this rather than thinking it may have just dropped into a black hole. :-) I will try to look at this in the next couple of days. The idea looks correct (although that was clear when you first suggested it), so it should be just a matter of sorting out any accidental mysteries in the code. I'll get back to you shortly. Cheers, Malcolm |