From sacadmin Wed Jul 4 21:25:50 2007 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l654PoD2019271 for ; Wed, 4 Jul 2007 21:25:50 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id l654O0JV010627 for ; Wed, 4 Jul 2007 21:24:00 -0700 (PDT) Received: from fe-amer-06.sun.com ([192.18.108.180]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l654Nxcv010667 for ; Thu, 5 Jul 2007 04:23:59 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JKO00201UPS7800@mail-amer.sun.com> (original mail from Brian.Cameron@Sun.COM) for LSARC@sac.sfbay.sun.com; Wed, 04 Jul 2007 22:23:58 -0600 (MDT) Received: from [129.158.219.142] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JKO001APUVWQFQ5@mail-amer.sun.com> for LSARC@sac.sfbay.sun.com; Wed, 04 Jul 2007 22:23:58 -0600 (MDT) Date: Thu, 05 Jul 2007 12:29:40 +0800 From: Brian Cameron Subject: Gamin - the File Alteration Monitor [LSARC/2007/398 Timeout: 07/18/2007] Sender: Brian.Cameron@Sun.COM To: LSARC@sac.sfbay.sun.com Message-id: <468C73B4.4060205@sun.com> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_PGG+Njo9EO26diWPOKy2jg)" User-Agent: Thunderbird 2.0.0.4 (X11/20070618) Status: RO Content-Length: 11071 This is a multi-part message in MIME format. --Boundary_(ID_PGG+Njo9EO26diWPOKy2jg) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT --Boundary_(ID_PGG+Njo9EO26diWPOKy2jg) Content-type: text/plain; name=one-pager-file-monitor.txt Content-transfer-encoding: 7BIT Content-disposition: inline; filename=one-pager-file-monitor.txt Template Version: @(#)onepager.txt 1.29 04/11/15 SMI 1. Introduction 1.1. Project/Component Working Name: Gamin - the File Alteration Monitor 1.2. Name of Document Author/Supplier: Henry Zhang (hua.zhang@sun.com) 1.3. Date of This Document: 06/23/07 1.4. Name of Major Document Customer(s)/Consumer(s): 1.4.1. The PAC or CPT you expect to review your project: Solaris PAC 1.4.2. The ARC(s) you expect to review your project: LSARC 1.4.3. The Director/VP who is "Sponsoring" this project: Robert.Odea@Sun.Com 1.4.4. The name of your business unit: JDS Desktop Engineering, OPG 1.5. Email Aliases: 1.5.1. Responsible Manager: leo.binchy@Sun.COM 1.5.2. Responsible Engineer: hua.zhang@Sun.COM 1.5.3. Marketing Manager: jeff.mcmeekin@sun.com 1.5.4. Interest List: Prakash.Sangappa@Sun.COM, Darren.Kenny@Sun.COM 2. Project Summary 2.1. Project Description: Gamin is a file and directory monitoring system providing a subset of the FAM (File Alteration Monitor) system interfaces. Gamin provides library interfaces that allow programs to detect when a file or directory has been modified. There are actually several backends for Gamin already - inotify, dnotify, kQueue, Hurd Mach Notify and a generic polling mechanism. Because our File Event Notification mechanism is ready for Solaris, we want to use it as the backend for Gamin and ship Gamin on Solairs. 2.2. Risks and Assumptions: By default Gamin should work without needing any configuration, but sometimes using the kernel notification APIs will not work or lead to troubles (for example when trying to unmount device). 3. Business Summary 3.1. Problem Area: Currently when using Nautilus on Solaris, if there is some change to some files/directory, the user will not immediately see the change without polling. And on Sun Ray, having to poll costs a lot of time/CPU/Network traffic. Sun currently modifies the panel menu and menu-editor code to work around the fact that we do not support file change notification. We currently run many find(1) searches to find updated files in Desk Search. The system will work more effectively when notification is added to the system. For example, consider a graphical file manager: When the user creates or removes a file through the file manager, their changes are visible immediately, as they should be. However, if they create or remove a file through some other means (such as typing "touch foo" or "rm foo" in a shell), some file managers will continue to display out-of-date information until the user manually directs the file manager to reread the contents of the directory. That is not the way it should be! The user should be able to trust that their file manager really shows the current file information, not the file information as it was at some unknown time in the past. Gaimin makes tools more usable by enabling them to respond to changes in the system. 3.2. Market/Requester: JDS Desktop group 3.3. Business Justification: GUI tools should not mislead the user where there is some changes on the file system. GUI tools should display the current state of the system, even when changes to the system originate from outside of the GUI tool. Gamin helps make GUI tools more usable by notifying them when the files they are interested in are created, modified, executed, and removed. Your application can use Gamin to get an up-to-date view of the filesystem rather than having to poll the filesystem. Typically, if applications need to monitor the status of a file or directory, they must periodically poll the filesystem. Gamin provides a more efficient and convenient method. We should not keep using polling for these changes, because : * Latency:need longer waiting time; * Duplication of effort: If you have many processes polling the same file, they are all going to have to periodically wake up, check the file, and go back to sleep. * Network traffic: When a process asks to watch a file that is NFS mounted from a remote host, polling will cause lots of network load. 3.4. Competitive Analysis: SGI IRIX uses FAM, and Linux uses FAM/Gamin to show users filesystem changes immediately. Windows has a similar machinism to show users filesystem changes when they happen. 3.5. Opportunity Window/Exposure: It is expected that this project will be integrated into Nevada B71. This project will also be integrated into Solaris 10 Updates if the backend FEN is also integrated into Solaris 10 Updates. At the moment, there is no plan to support FEN on Solaris 10 Update. 3.6. How will you know when you are done?: We will be done when Gamin is ported to Solaris, and runs correctly. Furthermore, the project will be complete when there are no stoppers, P1, or P2 bugs. 4. Technical Description: 4.1. Details: Gamin can report when a file is created, deleted, modified, or executed. See the new /usr/include/port.h for more details on what kind of changes FEN can handle. Basically Gaimin works exactly like the FAM interface. From a programmers point of view, the API is the same, and one can make use of the existing FAM documentation for reference. Gamin uses a client-server model. This is in a large measure justified by the inappropriate dnotify kernel API method to signal modification events to an application but also to share kernel signal when multiple applications monitor the same resource. It also allows fine tuning and filtering of the event flow in the daemon, potentially minimizing resource consumption in applications. Starting with release 0.0.21, Gamin comes with Python bindings. Python programs can "import gamin" to load the module. 4.2. Bug/RFE Number(s): N/A 4.3. In Scope: Port to Solaris Nevada. 4.4. Out of Scope: At the moment, we only port Gamin to Solaris Nevada, and not into Solaris 10 due to the FEN dependency. FEN changes some of the kernel data structures like the 'vnode', which could break third party software. If FEN is backported to Solaris 10 Update, then Gaimin should also be backported. 4.5. Interfaces: Imported Interfaces Interface Stability Comments ---------------- ------------ --------- /usr/lib/libglib-2.0.so.0 Committed /usr/lib/port.h Committed /lib/libsocket.so.1 Committed /lib/libnsl.so.1 Committed /lib/libscf.so.1 Evolving File Events Notification Committed See PSARC/2007/027 Exported Interfaces Stability Comments ------------------ ----------- -------- /usr/lib/gam_server Volatile /usr/lib/libfam.so.0.0.0 Volatile /usr/lib/libgamin-1.so.0.1.8 Volatile /usr/lib/python2.4/vendor-packages/gamin.py Volatile /usr/include/fam.h Volatile SUNWgamin Volatile SUNWgamin-devel Volatile 4.6. Doc Impact: N/A 4.7. Admin/Config Impact: No. 4.8. HA Impact: N/A 4.9. I18N/L10N Impact: No. 4.10. Packaging & Delivery: The new packages are: - SUNWgamin - SUNWgamin-devel 4.11. Security Impact: The ability to receive file notification events could provide a malicious user with information about the system. That said, Gaimin provides no information that the user could not acquire by other means. A user is only able to receive notification about files that they have permission to access. Therefore, systems that make use of file ownership/permissions in a secure way would be protected from exploit. 4.12. Dependencies: Because this project is based on File Events Notification API, it has a dependency on File Events Notification. Gaimin will not be delivered until FEN is delivered. File Events Notification API: see PSARC/2007/027/ 5. Reference Documents: Gamin Project TWiki home page: http://jdswiki.ireland.sun.com/twiki/bin/view/Vermillion/Gamin Gamin home page: http://www.gnome.org/~veillard/gamin/index.html File Events Notification API ARC home page: http://sac.sfbay.sun.com/arc/PSARC/2007/027/ FAM home page: http://oss.sgi.com/projects/fam/ 6. Resources and Schedule: 6.1. Projected Availability: Expect to integrate into Nevada in build 71 in Q3 2007. If FEN is backported into Solaris 10, then Gamin would also integrated into Solaris 10. 6.2. Cost of Effort: Phase one: Solaris Nevada Development 1.0 Engineers - 1 Months Testing 0.5 Engineers - 0.5 Months RE 0.5 Engineers - 0.5 Months Phase two: Solaris 10 Updates Yet to be scoped. 6.3. Cost of Capital Resources: N/A 6.4. Product Approval Committee requested information: 6.4.1. Consolidation or Component Name: JDS / OpenSolaris 6.4.3. Type of CPT Review and Approval expected: Standard 6.4.4. Project Boundary Conditions: none 6.4.5. Is this a necessary project for OEM agreements: No 6.4.6. Notes: N/A 6.4.7. Target RTI Date/Release: Nevada B71 - July 2007, and it will also be planed to put into Solaris 10 6.4.8. Target Code Design Review Date: July 2007 6.4.9. Update approval addition: New project, no Solaris PAC approval yet 6.5. ARC review type: FastTrack 7. Prototype Availability: 7.1. Prototype Availability: July 2007 7.2. Prototype Cost: 1 engineer 1 QA 1 RE --Boundary_(ID_PGG+Njo9EO26diWPOKy2jg)-- From sacadmin Thu Jul 5 11:29:13 2007 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l65ITDDY004329 for ; Thu, 5 Jul 2007 11:29:13 -0700 (PDT) Received: from sca-es-mail-1.sun.com (sca-es-mail-1.Sun.COM [192.18.43.132]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id l65IRM7Z005221 for ; Thu, 5 Jul 2007 11:27:22 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l65IRHGU002917 for ; Thu, 5 Jul 2007 11:27:17 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JKP00F01XPAS400@fe-sfbay-10.sun.com> (original mail from John.Fischer@Sun.COM) for LSARC@sac.sfbay.sun.com; Thu, 05 Jul 2007 11:27:17 -0700 (PDT) Received: from [129.145.154.105] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JKP002GLXXGGYF0@fe-sfbay-10.sun.com> for LSARC@sac.sfbay.sun.com; Thu, 05 Jul 2007 11:27:16 -0700 (PDT) Date: Thu, 05 Jul 2007 11:27:16 -0700 From: John.Fischer@Sun.COM Subject: Re: Gamin - the File Alteration Monitor [LSARC/2007/398 Timeout: 07/18/2007] In-reply-to: <468C73B4.4060205@sun.com> Sender: John.Fischer@Sun.COM To: Brian Cameron Cc: LSARC@sac.sfbay.sun.com Message-id: <468D3804.2030603@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <468C73B4.4060205@sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4v; en-US; rv:1.7) Gecko/20070109 Status: RO Content-Length: 11439 Brian, The packages: SUNWgamin Volatile SUNWgamin-devel Volatile Should be declared Uncommitted according to the Taxonomy Best Practice. Also it appears that the project is requesting a Minor release of Solaris. Is that correct? Or are they requesting a Patch release of Solaris? Thanks, John Brian Cameron wrote: >------------------------------------------------------------------------ > >Template Version: @(#)onepager.txt 1.29 04/11/15 SMI > >1. Introduction > > 1.1. Project/Component Working Name: > > Gamin - the File Alteration Monitor > > 1.2. Name of Document Author/Supplier: > > Henry Zhang (hua.zhang@sun.com) > > 1.3. Date of This Document: > > 06/23/07 > > 1.4. Name of Major Document Customer(s)/Consumer(s): > > 1.4.1. The PAC or CPT you expect to review your project: > > Solaris PAC > > 1.4.2. The ARC(s) you expect to review your project: > > LSARC > > 1.4.3. The Director/VP who is "Sponsoring" this project: > > Robert.Odea@Sun.Com > > 1.4.4. The name of your business unit: > > JDS Desktop Engineering, OPG > > 1.5. Email Aliases: > 1.5.1. Responsible Manager: leo.binchy@Sun.COM > 1.5.2. Responsible Engineer: hua.zhang@Sun.COM > 1.5.3. Marketing Manager: jeff.mcmeekin@sun.com > 1.5.4. Interest List: Prakash.Sangappa@Sun.COM, Darren.Kenny@Sun.COM > >2. Project Summary > > 2.1. Project Description: > > Gamin is a file and directory monitoring system providing a subset > of the FAM (File Alteration Monitor) system interfaces. Gamin provides > library interfaces that allow programs to detect when a file or > directory has been modified. There are actually several backends for > Gamin already - inotify, dnotify, kQueue, Hurd Mach Notify and a > generic polling mechanism. Because our File Event Notification > mechanism is ready for Solaris, we want to use it as the backend for > Gamin and ship Gamin on Solairs. > > 2.2. Risks and Assumptions: > > By default Gamin should work without needing any configuration, but > sometimes using the kernel notification APIs will not work or lead to > troubles (for example when trying to unmount device). > >3. Business Summary > > 3.1. Problem Area: > > Currently when using Nautilus on Solaris, if there is some change to > some files/directory, the user will not immediately see the change > without polling. And on Sun Ray, having to poll costs a lot of > time/CPU/Network traffic. Sun currently modifies the panel menu and > menu-editor code to work around the fact that we do not support file > change notification. We currently run many find(1) searches to find > updated files in Desk Search. The system will work more effectively > when notification is added to the system. > > For example, consider a graphical file manager: When the user creates > or removes a file through the file manager, their changes are visible > immediately, as they should be. However, if they create or remove a > file through some other means (such as typing "touch foo" or "rm foo" in > a shell), some file managers will continue to display out-of-date > information until the user manually directs the file manager to reread > the contents of the directory. That is not the way it should be! The > user should be able to trust that their file manager really shows the > current file information, not the file information as it was at some > unknown time in the past. Gaimin makes tools more usable by enabling > them to respond to changes in the system. > > 3.2. Market/Requester: > > JDS Desktop group > > 3.3. Business Justification: > > GUI tools should not mislead the user where there is some changes on > the file system. GUI tools should display the current state of the > system, even when changes to the system originate from outside of the > GUI tool. Gamin helps make GUI tools more usable by notifying them when > the files they are interested in are created, modified, executed, and > removed. > > Your application can use Gamin to get an up-to-date view of the > filesystem rather than having to poll the filesystem. Typically, if > applications need to monitor the status of a file or directory, they > must periodically poll the filesystem. Gamin provides a more efficient > and convenient method. > > We should not keep using polling for these changes, because : > * Latency:need longer waiting time; > * Duplication of effort: If you have many processes polling the > same file, they are all going to have to periodically wake up, > check the file, and go back to sleep. > * Network traffic: When a process asks to watch a file that is NFS > mounted from a remote host, polling will cause lots of network > load. > > 3.4. Competitive Analysis: > > SGI IRIX uses FAM, and Linux uses FAM/Gamin to show users filesystem > changes immediately. Windows has a similar machinism to show users > filesystem changes when they happen. > > 3.5. Opportunity Window/Exposure: > > It is expected that this project will be integrated into Nevada B71. > This project will also be integrated into Solaris 10 Updates if the > backend FEN is also integrated into Solaris 10 Updates. At the > moment, there is no plan to support FEN on Solaris 10 Update. > > 3.6. How will you know when you are done?: > > We will be done when Gamin is ported to Solaris, and runs correctly. > > Furthermore, the project will be complete when there are no stoppers, > P1, or P2 bugs. > >4. Technical Description: > > 4.1. Details: > > Gamin can report when a file is created, deleted, modified, or > executed. See the new /usr/include/port.h for more details on what > kind of changes FEN can handle. Basically Gaimin works exactly like > the FAM interface. From a programmers point of view, the API is the > same, and one can make use of the existing FAM documentation for > reference. > > Gamin uses a client-server model. This is in a large measure justified > by the inappropriate dnotify kernel API method to signal modification > events to an application but also to share kernel signal when multiple > applications monitor the same resource. It also allows fine tuning and > filtering of the event flow in the daemon, potentially minimizing > resource consumption in applications. > > Starting with release 0.0.21, Gamin comes with Python bindings. Python > programs can "import gamin" to load the module. > > 4.2. Bug/RFE Number(s): > > N/A > > 4.3. In Scope: > > Port to Solaris Nevada. > > 4.4. Out of Scope: > > At the moment, we only port Gamin to Solaris Nevada, and not into > Solaris 10 due to the FEN dependency. FEN changes some of the kernel > data structures like the 'vnode', which could break third party > software. If FEN is backported to Solaris 10 Update, then Gaimin > should also be backported. > > 4.5. Interfaces: > > Imported Interfaces > Interface Stability Comments > ---------------- ------------ --------- > > /usr/lib/libglib-2.0.so.0 Committed > /usr/lib/port.h Committed > /lib/libsocket.so.1 Committed > /lib/libnsl.so.1 Committed > /lib/libscf.so.1 Evolving > File Events Notification Committed See PSARC/2007/027 > > Exported Interfaces Stability Comments > ------------------ ----------- -------- > > /usr/lib/gam_server Volatile > /usr/lib/libfam.so.0.0.0 Volatile > /usr/lib/libgamin-1.so.0.1.8 Volatile > /usr/lib/python2.4/vendor-packages/gamin.py > Volatile > /usr/include/fam.h Volatile > SUNWgamin Volatile > SUNWgamin-devel Volatile > > 4.6. Doc Impact: > > N/A > > 4.7. Admin/Config Impact: > > No. > > 4.8. HA Impact: > > N/A > > 4.9. I18N/L10N Impact: > > No. > > 4.10. Packaging & Delivery: > > The new packages are: > - SUNWgamin > - SUNWgamin-devel > > 4.11. Security Impact: > > The ability to receive file notification events could provide a > malicious user with information about the system. That said, Gaimin > provides no information that the user could not acquire by other > means. A user is only able to receive notification about files that > they have permission to access. Therefore, systems that make use of > file ownership/permissions in a secure way would be protected from > exploit. > > 4.12. Dependencies: > > Because this project is based on File Events Notification API, it > has a dependency on File Events Notification. Gaimin will not be > delivered until FEN is delivered. > > File Events Notification API: see PSARC/2007/027/ > >5. Reference Documents: > > Gamin Project TWiki home page: > > http://jdswiki.ireland.sun.com/twiki/bin/view/Vermillion/Gamin > > Gamin home page: > > http://www.gnome.org/~veillard/gamin/index.html > > File Events Notification API ARC home page: > > http://sac.sfbay.sun.com/arc/PSARC/2007/027/ > > FAM home page: > > http://oss.sgi.com/projects/fam/ > >6. Resources and Schedule: > > 6.1. Projected Availability: > > Expect to integrate into Nevada in build 71 in Q3 2007. If FEN is > backported into Solaris 10, then Gamin would also integrated into > Solaris 10. > > 6.2. Cost of Effort: > > Phase one: Solaris Nevada > Development 1.0 Engineers - 1 Months > Testing 0.5 Engineers - 0.5 Months > RE 0.5 Engineers - 0.5 Months > > Phase two: Solaris 10 Updates > Yet to be scoped. > > 6.3. Cost of Capital Resources: > > N/A > > 6.4. Product Approval Committee requested information: > > 6.4.1. Consolidation or Component Name: > > JDS / OpenSolaris > > 6.4.3. Type of CPT Review and Approval expected: > > Standard > > 6.4.4. Project Boundary Conditions: > > none > > 6.4.5. Is this a necessary project for OEM agreements: > > No > > 6.4.6. Notes: > > N/A > > 6.4.7. Target RTI Date/Release: > > Nevada B71 - July 2007, and it will also be planed to put into > Solaris 10 > > 6.4.8. Target Code Design Review Date: > > July 2007 > > 6.4.9. Update approval addition: > > New project, no Solaris PAC approval yet > > 6.5. ARC review type: > > FastTrack > >7. Prototype Availability: > > 7.1. Prototype Availability: > > July 2007 > > 7.2. Prototype Cost: > > 1 engineer > 1 QA > 1 RE > > > From sacadmin Thu Jul 5 20:24:37 2007 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l663Ob3n017513 for ; Thu, 5 Jul 2007 20:24:37 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id l663MkfQ003223 for ; Thu, 5 Jul 2007 20:22:46 -0700 (PDT) Received: from fe-amer-02.sun.com ([192.18.108.176]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l663Mjaj000949 for ; Fri, 6 Jul 2007 03:22:46 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JKQ00501LT8BX00@mail-amer.sun.com> (original mail from Brian.Cameron@Sun.COM) for LSARC@sac.sfbay.sun.com; Thu, 05 Jul 2007 21:22:45 -0600 (MDT) Received: from [10.128.0.133] ([219.143.199.162]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JKQ00GZHMPVF3O5@mail-amer.sun.com> for LSARC@sac.sfbay.sun.com; Thu, 05 Jul 2007 21:22:45 -0600 (MDT) Date: Fri, 06 Jul 2007 11:28:26 +0800 From: Brian Cameron Subject: Re: Gamin - the File Alteration Monitor [LSARC/2007/398 Timeout: 07/18/2007] In-reply-to: <468D3804.2030603@Sun.COM> Sender: Brian.Cameron@Sun.COM To: John.Fischer@Sun.COM Cc: LSARC@sac.sfbay.sun.com Message-id: <468DB6DA.802@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <468C73B4.4060205@sun.com> <468D3804.2030603@Sun.COM> User-Agent: Thunderbird 2.0.0.4 (X11/20070618) Status: RO Content-Length: 12288 John: > The packages: > > SUNWgamin Volatile > SUNWgamin-devel Volatile > > Should be declared Uncommitted according to the > Taxonomy Best Practice. Thanks for the heads up. I'll update the ARC FastTrack with this. > Also it appears that the project is requesting a Minor release of > Solaris. Is that correct? Or are they requesting a Patch release of > Solaris? No, this project is requesting only to go into Nevada, *not* a S10U release. The project team just wanted to highlight that if FAM is made available in a future S10U patch release that Gamin will also want to be released in the same S10U patch release. Since there are no plans to release FAM in S10U, this project only intends to integrate into Nevada. Brian > Brian Cameron wrote: > >> ------------------------------------------------------------------------ >> >> Template Version: @(#)onepager.txt 1.29 04/11/15 SMI >> >> 1. Introduction >> >> 1.1. Project/Component Working Name: >> >> Gamin - the File Alteration Monitor >> 1.2. Name of Document Author/Supplier: >> >> Henry Zhang (hua.zhang@sun.com) >> >> 1.3. Date of This Document: >> >> 06/23/07 >> >> 1.4. Name of Major Document Customer(s)/Consumer(s): >> >> 1.4.1. The PAC or CPT you expect to review your project: >> >> Solaris PAC >> >> 1.4.2. The ARC(s) you expect to review your project: >> >> LSARC >> >> 1.4.3. The Director/VP who is "Sponsoring" this project: >> >> Robert.Odea@Sun.Com >> >> 1.4.4. The name of your business unit: >> >> JDS Desktop Engineering, OPG >> >> 1.5. Email Aliases: >> 1.5.1. Responsible Manager: leo.binchy@Sun.COM >> 1.5.2. Responsible Engineer: hua.zhang@Sun.COM >> 1.5.3. Marketing Manager: jeff.mcmeekin@sun.com >> 1.5.4. Interest List: Prakash.Sangappa@Sun.COM, >> Darren.Kenny@Sun.COM >> >> 2. Project Summary >> >> 2.1. Project Description: >> >> Gamin is a file and directory monitoring system providing a subset >> of the FAM (File Alteration Monitor) system interfaces. Gamin >> provides >> library interfaces that allow programs to detect when a file or >> directory has been modified. There are actually several >> backends for Gamin already - inotify, dnotify, kQueue, Hurd Mach >> Notify and a generic polling mechanism. Because our File Event >> Notification >> mechanism is ready for Solaris, we want to use it as the backend >> for >> Gamin and ship Gamin on Solairs. >> 2.2. Risks and Assumptions: >> >> By default Gamin should work without needing any configuration, >> but sometimes using the kernel notification APIs will not work >> or lead to troubles (for example when trying to unmount device). >> 3. Business Summary >> >> 3.1. Problem Area: >> >> Currently when using Nautilus on Solaris, if there is some >> change to >> some files/directory, the user will not immediately see the >> change without polling. And on Sun Ray, having to poll costs a >> lot of >> time/CPU/Network traffic. Sun currently modifies the panel menu >> and >> menu-editor code to work around the fact that we do not support >> file >> change notification. We currently run many find(1) searches to find >> updated files in Desk Search. The system will work more >> effectively >> when notification is added to the system. >> >> For example, consider a graphical file manager: When the user >> creates or removes a file through the file manager, their >> changes are visible immediately, as they should be. However, if >> they create or remove a file through some other means (such as >> typing "touch foo" or "rm foo" in a shell), some file managers >> will continue to display out-of-date information until the user >> manually directs the file manager to reread the contents of the >> directory. That is not the way it should be! The user should be >> able to trust that their file manager really shows the >> current file information, not the file information as it was at >> some >> unknown time in the past. Gaimin makes tools more usable by >> enabling >> them to respond to changes in the system. >> >> 3.2. Market/Requester: >> >> JDS Desktop group >> >> 3.3. Business Justification: >> GUI tools should not mislead the user where there is some >> changes on >> the file system. GUI tools should display the current state of >> the system, even when changes to the system originate from >> outside of the GUI tool. Gamin helps make GUI tools more usable >> by notifying them when >> the files they are interested in are created, modified, >> executed, and >> removed. >> >> Your application can use Gamin to get an up-to-date view of the >> filesystem rather than having to poll the filesystem. Typically, >> if applications need to monitor the status of a file or >> directory, they must periodically poll the filesystem. Gamin >> provides a more efficient and convenient method. >> >> We should not keep using polling for these changes, because : >> * Latency:need longer waiting time; * Duplication >> of effort: If you have many processes polling the same >> file, they are all going to have to periodically wake up, >> check the file, and go back to sleep. >> * Network traffic: When a process asks to watch a file that >> is NFS mounted from a remote host, polling will cause lots >> of network load. >> >> 3.4. Competitive Analysis: >> >> SGI IRIX uses FAM, and Linux uses FAM/Gamin to show users >> filesystem >> changes immediately. Windows has a similar machinism to show users >> filesystem changes when they happen. >> >> 3.5. Opportunity Window/Exposure: >> >> It is expected that this project will be integrated into Nevada >> B71. >> This project will also be integrated into Solaris 10 Updates if the >> backend FEN is also integrated into Solaris 10 Updates. At the >> moment, there is no plan to support FEN on Solaris 10 Update. >> >> 3.6. How will you know when you are done?: >> >> We will be done when Gamin is ported to Solaris, and runs >> correctly. >> >> Furthermore, the project will be complete when there are no >> stoppers, >> P1, or P2 bugs. >> >> 4. Technical Description: >> >> 4.1. Details: >> >> Gamin can report when a file is created, deleted, modified, or >> executed. See the new /usr/include/port.h for more details on >> what kind of changes FEN can handle. Basically Gaimin works >> exactly like >> the FAM interface. From a programmers point of view, the API is the >> same, and one can make use of the existing FAM documentation for >> reference. >> >> Gamin uses a client-server model. This is in a large measure >> justified >> by the inappropriate dnotify kernel API method to signal >> modification events to an application but also to share kernel >> signal when multiple applications monitor the same resource. It >> also allows fine tuning and >> filtering of the event flow in the daemon, potentially minimizing >> resource consumption in applications. >> >> Starting with release 0.0.21, Gamin comes with Python bindings. >> Python >> programs can "import gamin" to load the module. >> >> 4.2. Bug/RFE Number(s): >> >> N/A >> >> 4.3. In Scope: >> >> Port to Solaris Nevada. >> >> 4.4. Out of Scope: >> >> At the moment, we only port Gamin to Solaris Nevada, and not >> into Solaris 10 due to the FEN dependency. FEN changes some of >> the kernel >> data structures like the 'vnode', which could break third party >> software. If FEN is backported to Solaris 10 Update, then >> Gaimin should also be backported. >> >> 4.5. Interfaces: >> Imported Interfaces >> Interface Stability Comments >> ---------------- ------------ --------- >> >> /usr/lib/libglib-2.0.so.0 Committed >> /usr/lib/port.h Committed >> /lib/libsocket.so.1 Committed >> /lib/libnsl.so.1 Committed >> /lib/libscf.so.1 Evolving >> File Events Notification Committed See PSARC/2007/027 >> >> Exported Interfaces Stability Comments >> ------------------ ----------- -------- >> >> /usr/lib/gam_server Volatile >> /usr/lib/libfam.so.0.0.0 Volatile >> /usr/lib/libgamin-1.so.0.1.8 Volatile >> /usr/lib/python2.4/vendor-packages/gamin.py >> Volatile >> /usr/include/fam.h Volatile >> SUNWgamin Volatile >> SUNWgamin-devel Volatile >> >> 4.6. Doc Impact: >> >> N/A >> >> 4.7. Admin/Config Impact: >> >> No. >> 4.8. HA Impact: >> >> N/A >> >> 4.9. I18N/L10N Impact: >> >> No. >> >> 4.10. Packaging & Delivery: >> >> The new packages are: >> - SUNWgamin >> - SUNWgamin-devel >> >> 4.11. Security Impact: >> >> The ability to receive file notification events could provide a >> malicious user with information about the system. That said, >> Gaimin >> provides no information that the user could not acquire by >> other means. A user is only able to receive notification about >> files that >> they have permission to access. Therefore, systems that make >> use of >> file ownership/permissions in a secure way would be protected from >> exploit. >> >> 4.12. Dependencies: >> >> Because this project is based on File Events Notification API, it >> has a dependency on File Events Notification. Gaimin will not be >> delivered until FEN is delivered. >> >> File Events Notification API: see PSARC/2007/027/ >> >> 5. Reference Documents: >> >> Gamin Project TWiki home page: >> http://jdswiki.ireland.sun.com/twiki/bin/view/Vermillion/Gamin >> >> Gamin home page: >> http://www.gnome.org/~veillard/gamin/index.html >> >> File Events Notification API ARC home page: >> >> http://sac.sfbay.sun.com/arc/PSARC/2007/027/ >> >> FAM home page: >> >> http://oss.sgi.com/projects/fam/ >> >> 6. Resources and Schedule: >> >> 6.1. Projected Availability: >> Expect to integrate into Nevada in build 71 in Q3 2007. >> If FEN is backported into Solaris 10, then Gamin would also >> integrated into Solaris 10. >> >> 6.2. Cost of Effort: >> >> Phase one: Solaris Nevada >> Development 1.0 Engineers - 1 Months >> Testing 0.5 Engineers - 0.5 Months >> RE 0.5 Engineers - 0.5 Months >> >> Phase two: Solaris 10 Updates >> Yet to be scoped. >> >> 6.3. Cost of Capital Resources: >> >> N/A >> >> 6.4. Product Approval Committee requested information: >> >> 6.4.1. Consolidation or Component Name: >> >> JDS / OpenSolaris >> >> 6.4.3. Type of CPT Review and Approval expected: >> >> Standard >> >> 6.4.4. Project Boundary Conditions: >> >> none >> >> 6.4.5. Is this a necessary project for OEM agreements: >> >> No >> >> 6.4.6. Notes: >> >> N/A >> >> 6.4.7. Target RTI Date/Release: >> >> Nevada B71 - July 2007, and it will also be planed to put >> into Solaris 10 >> >> 6.4.8. Target Code Design Review Date: >> >> July 2007 >> >> 6.4.9. Update approval addition: >> >> New project, no Solaris PAC approval yet >> >> 6.5. ARC review type: >> >> FastTrack >> >> 7. Prototype Availability: >> >> 7.1. Prototype Availability: >> >> July 2007 >> 7.2. Prototype Cost: >> >> 1 engineer >> 1 QA >> 1 RE >> >> >> > From sacadmin Fri Jul 6 09:31:50 2007 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l66GVoJe000533 for ; Fri, 6 Jul 2007 09:31:50 -0700 (PDT) Received: from sca-es-mail-1.sun.com (sca-es-mail-1.Sun.COM [192.18.43.132]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l66GTw9D015413 for ; Fri, 6 Jul 2007 09:29:59 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l66GTrZW007389 for ; Fri, 6 Jul 2007 09:29:53 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JKR00A01MZZ3300@fe-sfbay-09.sun.com> (original mail from John.Fischer@Sun.COM) for LSARC@sac.sfbay.sun.com; Fri, 06 Jul 2007 09:29:53 -0700 (PDT) Received: from [129.150.12.240] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JKR000ALN5TCI40@fe-sfbay-09.sun.com> for LSARC@sac.sfbay.sun.com; Fri, 06 Jul 2007 09:29:53 -0700 (PDT) Date: Fri, 06 Jul 2007 09:29:43 -0700 From: John Fischer Subject: Re: Gamin - the File Alteration Monitor [LSARC/2007/398 Timeout: 07/18/2007] In-reply-to: <468DB6DA.802@sun.com> Sender: John.Fischer@Sun.COM To: Brian Cameron Cc: LSARC@sac.sfbay.sun.com Message-id: <468E6DF7.5000700@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <468C73B4.4060205@sun.com> <468D3804.2030603@Sun.COM> <468DB6DA.802@sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20051027 Status: RO Content-Length: 649 Brian, That sounds like the release binding is a Minor release of Solaris. Thanks, John Brian Cameron wrote: >> Also it appears that the project is requesting a Minor release of >> Solaris. Is that correct? Or are they requesting a Patch release of >> Solaris? > > > No, this project is requesting only to go into Nevada, *not* a S10U > release. > > The project team just wanted to highlight that if FAM is made > available in a future S10U patch release that Gamin will also want > to be released in the same S10U patch release. > > Since there are no plans to release FAM in S10U, this project only > intends to integrate into Nevada. From sacadmin Wed Aug 1 16:30:17 2007 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l71NUH0R003817 for ; Wed, 1 Aug 2007 16:30:17 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l71NS1RF011997 for ; Wed, 1 Aug 2007 16:28:01 -0700 (PDT) Received: from fe-amer-01.sun.com ([192.18.108.175]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l71NS10Y027207 for ; Wed, 1 Aug 2007 23:28:01 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JM400A01B998700@mail-amer.sun.com> (original mail from Brian.Cameron@Sun.COM) for LSARC@sac.sfbay.sun.com; Wed, 01 Aug 2007 17:28:01 -0600 (MDT) Received: from [129.152.10.108] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JM400FQ2BUOC4X2@mail-amer.sun.com> for LSARC@sac.sfbay.sun.com; Wed, 01 Aug 2007 17:28:01 -0600 (MDT) Date: Wed, 01 Aug 2007 18:26:21 -0500 From: Brian Cameron Subject: Gamin - the File Alteration Monitor [LSARC/2007/398 Timeout: 07/18/2007] Sender: Brian.Cameron@Sun.COM To: LSARC@sac.sfbay.sun.com Message-id: <46B1169D.3050502@sun.com> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_O/R+2fwvpH1DarXDmHBzlw)" User-Agent: Thunderbird 2.0.0.4 (X11/20070618) Status: RO Content-Length: 11502 This is a multi-part message in MIME format. --Boundary_(ID_O/R+2fwvpH1DarXDmHBzlw) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT LSARC: We have now passed the timeout for the "LSARC 2007/398 Gamin - the File Alteration Monitor" FastTrack case and since there were no comments this case is now marked as closed approved. Brian -------- Original Message -------- Subject: Gamin - the File Alteration Monitor [LSARC/2007/398 Timeout: 07/18/2007] Date: Thu, 05 Jul 2007 12:29:40 +0800 From: Brian Cameron To: LSARC@sac.sfbay.sun.com --Boundary_(ID_O/R+2fwvpH1DarXDmHBzlw) Content-type: text/plain; name=one-pager-file-monitor.txt Content-transfer-encoding: 7BIT Content-disposition: inline; filename=one-pager-file-monitor.txt Template Version: @(#)onepager.txt 1.29 04/11/15 SMI 1. Introduction 1.1. Project/Component Working Name: Gamin - the File Alteration Monitor 1.2. Name of Document Author/Supplier: Henry Zhang (hua.zhang@sun.com) 1.3. Date of This Document: 06/23/07 1.4. Name of Major Document Customer(s)/Consumer(s): 1.4.1. The PAC or CPT you expect to review your project: Solaris PAC 1.4.2. The ARC(s) you expect to review your project: LSARC 1.4.3. The Director/VP who is "Sponsoring" this project: Robert.Odea@Sun.Com 1.4.4. The name of your business unit: JDS Desktop Engineering, OPG 1.5. Email Aliases: 1.5.1. Responsible Manager: leo.binchy@Sun.COM 1.5.2. Responsible Engineer: hua.zhang@Sun.COM 1.5.3. Marketing Manager: jeff.mcmeekin@sun.com 1.5.4. Interest List: Prakash.Sangappa@Sun.COM, Darren.Kenny@Sun.COM 2. Project Summary 2.1. Project Description: Gamin is a file and directory monitoring system providing a subset of the FAM (File Alteration Monitor) system interfaces. Gamin provides library interfaces that allow programs to detect when a file or directory has been modified. There are actually several backends for Gamin already - inotify, dnotify, kQueue, Hurd Mach Notify and a generic polling mechanism. Because our File Event Notification mechanism is ready for Solaris, we want to use it as the backend for Gamin and ship Gamin on Solairs. 2.2. Risks and Assumptions: By default Gamin should work without needing any configuration, but sometimes using the kernel notification APIs will not work or lead to troubles (for example when trying to unmount device). 3. Business Summary 3.1. Problem Area: Currently when using Nautilus on Solaris, if there is some change to some files/directory, the user will not immediately see the change without polling. And on Sun Ray, having to poll costs a lot of time/CPU/Network traffic. Sun currently modifies the panel menu and menu-editor code to work around the fact that we do not support file change notification. We currently run many find(1) searches to find updated files in Desk Search. The system will work more effectively when notification is added to the system. For example, consider a graphical file manager: When the user creates or removes a file through the file manager, their changes are visible immediately, as they should be. However, if they create or remove a file through some other means (such as typing "touch foo" or "rm foo" in a shell), some file managers will continue to display out-of-date information until the user manually directs the file manager to reread the contents of the directory. That is not the way it should be! The user should be able to trust that their file manager really shows the current file information, not the file information as it was at some unknown time in the past. Gaimin makes tools more usable by enabling them to respond to changes in the system. 3.2. Market/Requester: JDS Desktop group 3.3. Business Justification: GUI tools should not mislead the user where there is some changes on the file system. GUI tools should display the current state of the system, even when changes to the system originate from outside of the GUI tool. Gamin helps make GUI tools more usable by notifying them when the files they are interested in are created, modified, executed, and removed. Your application can use Gamin to get an up-to-date view of the filesystem rather than having to poll the filesystem. Typically, if applications need to monitor the status of a file or directory, they must periodically poll the filesystem. Gamin provides a more efficient and convenient method. We should not keep using polling for these changes, because : * Latency:need longer waiting time; * Duplication of effort: If you have many processes polling the same file, they are all going to have to periodically wake up, check the file, and go back to sleep. * Network traffic: When a process asks to watch a file that is NFS mounted from a remote host, polling will cause lots of network load. 3.4. Competitive Analysis: SGI IRIX uses FAM, and Linux uses FAM/Gamin to show users filesystem changes immediately. Windows has a similar machinism to show users filesystem changes when they happen. 3.5. Opportunity Window/Exposure: It is expected that this project will be integrated into Nevada B71. This project will also be integrated into Solaris 10 Updates if the backend FEN is also integrated into Solaris 10 Updates. At the moment, there is no plan to support FEN on Solaris 10 Update. 3.6. How will you know when you are done?: We will be done when Gamin is ported to Solaris, and runs correctly. Furthermore, the project will be complete when there are no stoppers, P1, or P2 bugs. 4. Technical Description: 4.1. Details: Gamin can report when a file is created, deleted, modified, or executed. See the new /usr/include/port.h for more details on what kind of changes FEN can handle. Basically Gaimin works exactly like the FAM interface. From a programmers point of view, the API is the same, and one can make use of the existing FAM documentation for reference. Gamin uses a client-server model. This is in a large measure justified by the inappropriate dnotify kernel API method to signal modification events to an application but also to share kernel signal when multiple applications monitor the same resource. It also allows fine tuning and filtering of the event flow in the daemon, potentially minimizing resource consumption in applications. Starting with release 0.0.21, Gamin comes with Python bindings. Python programs can "import gamin" to load the module. 4.2. Bug/RFE Number(s): N/A 4.3. In Scope: Port to Solaris Nevada. 4.4. Out of Scope: At the moment, we only port Gamin to Solaris Nevada, and not into Solaris 10 due to the FEN dependency. FEN changes some of the kernel data structures like the 'vnode', which could break third party software. If FEN is backported to Solaris 10 Update, then Gaimin should also be backported. 4.5. Interfaces: Imported Interfaces Interface Stability Comments ---------------- ------------ --------- /usr/lib/libglib-2.0.so.0 Committed /usr/lib/port.h Committed /lib/libsocket.so.1 Committed /lib/libnsl.so.1 Committed /lib/libscf.so.1 Evolving File Events Notification Committed See PSARC/2007/027 Exported Interfaces Stability Comments ------------------ ----------- -------- /usr/lib/gam_server Volatile /usr/lib/libfam.so.0.0.0 Volatile /usr/lib/libgamin-1.so.0.1.8 Volatile /usr/lib/python2.4/vendor-packages/gamin.py Volatile /usr/include/fam.h Volatile SUNWgamin Volatile SUNWgamin-devel Volatile 4.6. Doc Impact: N/A 4.7. Admin/Config Impact: No. 4.8. HA Impact: N/A 4.9. I18N/L10N Impact: No. 4.10. Packaging & Delivery: The new packages are: - SUNWgamin - SUNWgamin-devel 4.11. Security Impact: The ability to receive file notification events could provide a malicious user with information about the system. That said, Gaimin provides no information that the user could not acquire by other means. A user is only able to receive notification about files that they have permission to access. Therefore, systems that make use of file ownership/permissions in a secure way would be protected from exploit. 4.12. Dependencies: Because this project is based on File Events Notification API, it has a dependency on File Events Notification. Gaimin will not be delivered until FEN is delivered. File Events Notification API: see PSARC/2007/027/ 5. Reference Documents: Gamin Project TWiki home page: http://jdswiki.ireland.sun.com/twiki/bin/view/Vermillion/Gamin Gamin home page: http://www.gnome.org/~veillard/gamin/index.html File Events Notification API ARC home page: http://sac.sfbay.sun.com/arc/PSARC/2007/027/ FAM home page: http://oss.sgi.com/projects/fam/ 6. Resources and Schedule: 6.1. Projected Availability: Expect to integrate into Nevada in build 71 in Q3 2007. If FEN is backported into Solaris 10, then Gamin would also integrated into Solaris 10. 6.2. Cost of Effort: Phase one: Solaris Nevada Development 1.0 Engineers - 1 Months Testing 0.5 Engineers - 0.5 Months RE 0.5 Engineers - 0.5 Months Phase two: Solaris 10 Updates Yet to be scoped. 6.3. Cost of Capital Resources: N/A 6.4. Product Approval Committee requested information: 6.4.1. Consolidation or Component Name: JDS / OpenSolaris 6.4.3. Type of CPT Review and Approval expected: Standard 6.4.4. Project Boundary Conditions: none 6.4.5. Is this a necessary project for OEM agreements: No 6.4.6. Notes: N/A 6.4.7. Target RTI Date/Release: Nevada B71 - July 2007, and it will also be planed to put into Solaris 10 6.4.8. Target Code Design Review Date: July 2007 6.4.9. Update approval addition: New project, no Solaris PAC approval yet 6.5. ARC review type: FastTrack 7. Prototype Availability: 7.1. Prototype Availability: July 2007 7.2. Prototype Cost: 1 engineer 1 QA 1 RE --Boundary_(ID_O/R+2fwvpH1DarXDmHBzlw)--