From sacadmin Wed Aug 15 10:47:31 2007 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l7FHlVoh016145 for ; Wed, 15 Aug 2007 10:47:31 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l7FHioXS030059 for <@sunmail2sca.sfbay.sun.com:psarc@sun.com>; Wed, 15 Aug 2007 11:44:51 -0600 (MDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JMT00703TB2A600@brm-avmta-1.central.sun.com> for psarc@sun.com (ORCPT psarc@sun.com); Wed, 15 Aug 2007 11:45:02 -0600 (MDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JMT0021HTB0NDD0@brm-avmta-1.central.sun.com> for psarc@sun.com (ORCPT psarc@sun.com); Wed, 15 Aug 2007 11:45:01 -0600 (MDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l7FHj0Tx014556 for ; Wed, 15 Aug 2007 10:45:00 -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 <0JMT00J01TAXNA00@fe-sfbay-10.sun.com> (original mail from John.Fischer@Sun.COM) for psarc@sun.com (ORCPT psarc@sun.com); Wed, 15 Aug 2007 10:45:00 -0700 (PDT) Received: from [129.150.12.240] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JMT00767TB0NKE0@fe-sfbay-10.sun.com>; Wed, 15 Aug 2007 10:45:00 -0700 (PDT) Date: Wed, 15 Aug 2007 10:44:07 -0700 From: John Fischer Subject: LSARC/2006/455 Avahi and libdaemon Sender: John.Fischer@sun.com To: lsarc-ext@sac.sfbay.sun.com, "Padraig O'Briain" Cc: psarc@sun.com Message-id: <46C33B67.7000904@sun.com> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_qwZu/jP+dcv8yBUrg9qptw)" X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20051027 Status: RO Content-Length: 12914 This is a multi-part message in MIME format. --Boundary_(ID_qwZu/jP+dcv8yBUrg9qptw) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT All, I am sponsoring this fast track for Padraig O'Briain from the JDS - Gnome team in Ireland. The case directory contains this proposal and man pages for the various commands. I have set the timer for Wednesday August 22nd, 2007. This project provides an alternative implementation to the Multicast DNS (mDNS) and Service Discovery project (aka Bonjour). This project is needed to provide support for various Gnome components. The project delivers the avahi client API. Instead of delivering the avahi daemon, which on linux and freebsd implements a mDNS stack, the project will change the avahi daemon to make calls to the Bonjour API so that it will use the Bonjour server. The project is requesting a Minor release of Solaris. Thanks, John --Boundary_(ID_qwZu/jP+dcv8yBUrg9qptw) Content-type: text/plain; name=proposal.txt Content-transfer-encoding: 7BIT Content-disposition: inline; filename=proposal.txt 1. Introduction 1.1. Project/Component Working Name: Avahi and libdaemon 1.2. Name of Document Author/Supplier: Padraig O'Briain 1.3. The name of your business unit: JDS Desktop Engineering, Open Source Software, OPG 1.4. Email Aliases: 1.4.1. Responsible Manager: Leo Binchy 1.4.2. Responsible Engineer: Padraig O'Briain 1.4.3. Marketing Manager: Jeff Mc Meekin 1.4.4. Interest List: desktop-cteam@sun.com nwam-bonjour@sun.com bonjour-iteam@sun.com 2. Project Summary 2.1. Project Description: The Multicast DNS (mDNS) and Service Discovery project introduces DNS server-less link-local IP address resolution for ad-hoc networks and discovery of devices and services. See PSARC/2005/562. That project is based on Apple's implementation, a.k.a Bonjour. An alternative implementation is avahi, see www.avahi.org. Some GNOME components provide support for service registration and discovery using avahi. This project delivers the avahi client API. Instead of delivering the avahi daemon, which on linux and freebsd implements a mDNS stack, we will change the avahi daemon to make calls to the Bonjour API so that it will use the Bonjour server. Thus this project depends on PSARC/2005/562. libdaemon is a lightweight C library that eases the writing of UNIX daemons and is used by the avahi daemon. 4. Technical Description: 4.1. Details: Avahi consists of several parts: libavahi-common: a library containing some functions used by avahi clients and the avahi daemon itself. libavahi-core: A library implement service registration and discovery. libavahi-client: A minimal wrapper around the DBUS API to simplify its usage. It hides the DBUS internals completely. libavahi-glib: An adaptor for connecting avahi-client or avahi-core to a GLIB main loop. avahi-daemon: The avahi daemon makes use of libavahi-core to provide service registration and discovery to clients using the DBUS interface which is an IPC wrapper around the functions provided by avahi-core. We rename this to avahi-daemon-bridge-dsd so that it is clear that we are not delivering the standard avahi daemon. avahi-browse, avahi-discover, avahi-publish, avahi-resolve: Some command line utilities which use libavahi-client. See http://www.avahi.org/wiki/ArchitecturalOverview, which lists some other parts of avahi which we do not deliver. We make significant changes to avahi daemon and libavahi-core. Instead of implementing a mDNS/DNS-SD stack libavahi-core makes calls to the DNS Service Discovery API provided by Bonjour to register and discover services. As the avahi daemon does not provide service registration and discovery itself those portions related to being a mDNS server are omitted. libdaemon is a lightweight C library that eases the writing of UNIX daemons. It consists of the following parts: * A wrapper around fork() which does the correct daemonization procedure of a process * A wrapper around syslog() for simpler and compatible log output to Syslog or STDERR * An API for writing PID files * An API for serializing UNIX signals into a pipe for usage with select() or poll() * An API for running subprocesses with STDOUT and STDERR redirected to syslog. 4.2. Bug/RFE Number(s): N/A. 4.3. In Scope: The project team will integrate and support versions of Avahi continually throughout its life within the Solaris OS. The project team will mark the interfaces of Avahi as appropriate [detailed below] and work with other project teams to provide contracts of use, until such a stage where the technology can be considered as 'Committed' according to the interface taxonomy rules. 4.4. Out of Scope: Sun does not expect to be involved in the development and direction of avahi or libdaemon. Where possible, we will ship 'as is', with the changes to call Bonjour. Any developer changes will be pushed upstream where appropriate. 4.5. Interfaces: Exported Interfaces SUNWlibdaemon Uncommitted Package name for libdaemon Two packages SUNWlibdaemon and SUNWlibdaemon-devel are delivered. /usr/lib/libdaemon.so Volatile libdaemon C library /usr/lib/pkgconfig/libdaemon.pc pkgconfig file for Volatile libdaemon Volatile libdaemon API /usr/include/libdaemon/daemon.h /usr/include/libdaemon/dexec.h /usr/include/libdaemon/dfork.h /usr/include/libdaemon/dlog.h /usr/include/libdaemon/dnoblock.h /usr/include/libdaemon/dpid.h /usr/include/libdaemon/dsignal.h SUNWavahi-bridge-dsd Uncommitted Package name for avahi. Three packages SUNWavahi-bridge-dsd, SUNWavahi-bridge-dsd-devel and SUNWavahi-bridge-dsd-root are delivered. /etc/dbus-1/system.d/avahi-dbus.conf Configuration file for Volatile avahi DBUS messages. /etc/avahi/hosts Volatile address host mappings /etc/avahi/services/ssh.service Volatile Static service /var/run/avahi-daemon-bridge-dsd/pid Project Private PID file for avahi. svc:/system/avahi-bridge-dsd:default Volatile SMF service to start avahi-daemon-bridge-dsd. Volatile Avahi APIs. /usr/include/avahi-client/client.h /usr/include/avahi-client/lookup.h /usr/include/avahi-client/publish.h /usr/include/avahi-common/address.h /usr/include/avahi-common/address.h /usr/include/avahi-common/alternative.h /usr/include/avahi-common/cdecl.h /usr/include/avahi-common/defs.h /usr/include/avahi-common/domain.h /usr/include/avahi-common/error.h /usr/include/avahi-common/gccmacro.h /usr/include/avahi-common/llist.h /usr/include/avahi-common/malloc.h /usr/include/avahi-common/rlist.h /usr/include/avahi-common/simple-watch.h /usr/include/avahi-common/strlst.h /usr/include/avahi-common/thread-watch.h /usr/include/avahi-common/timeval.h /usr/include/avahi-common/watch.h /usr/include/avahi-core/core.h /usr/include/avahi-core/log.h /usr/include/avahi-core/lookup.h /usr/include/avahi-core/publish.h /usr/include/avahi-core/rr.h /usr/include/avahi-glib/glib-malloc.h /usr/include/avahi-glib/glib-watch.h /usr/lib/pkgconfig/avahi-client.pc pkgconfig files for /usr/lib/pkgconfig/avahi-core.pc avahi-core, avahi-client /usr/lib/pkgconfig/avahi-glib.pc and avahi-glib bindings. Volatile /usr/bin/avahi-browse Volatile Command line utilities /usr/bin/avahi-discover /usr/bin/bssh /usr/bin/bvnc (this is a link to /usr/bin/bssh) /usr/share/avahi/interfaces/avahi-discover.glade /usr/share/applications/avahi-discover.desktop /usr/bin/avahi-publish /usr/bin/avahi-resolve /usr/bin/avahi-set-host-name /usr/sbin/avahi-daemon-bridge-dsd Volatile Avahi server daemon. Volatile Avahi libraries /usr/lib/libavahi-client.so.3.2.0 /usr/lib/libavahi-common.so.3.4.2 /usr/lib/libavahi-core.so.4.0.4 /usr/lib/libavahi-glib.so.1.0.1 Volatile Avahi python bindings /usr/lib/python2.4/vendor-packages/avahi/ServiceTypeDatabase.py /usr/lib/python2.4/vendor-packages/avahi/SimpleGladeApp.py /usr/lib/python2.4/vendor-packages/avahi/SimpleGladeApp.pyc /usr/lib/python2.4/vendor-packages/avahi/__init__.py /usr/lib/python2.4/vendor-packages/avahi/__init__.pyc Volatile Avahi DBUS Introspection /usr/share/avahi/introspection/AddressResolver.introspect /usr/share/avahi/introspection/DomainBrowser.introspect /usr/share/avahi/introspection/EntryGroup.introspect /usr/share/avahi/introspection/HostNameResolver.introspect /usr/share/avahi/introspection/RecordBrowser.introspect /usr/share/avahi/introspection/Server.introspect /usr/share/avahi/introspection/ServiceBrowser.introspect /usr/share/avahi/introspection/ServiceResolver.introspect /usr/share/avahi/introspection/ServiceTypeBrowser.introspect Volatile Avahi Service Types database /usr/share/avahi/service-types /usr/share/avahi/service-types.DB.Dir /usr/share/avahi/service-types.db.pag /usr/share/avahi/avahi-service.dtd Volatile Man pages /usr/share/man/man1/avahi-browse.1 /usr/share/man/man1/avahi-daemon-bridge-dsd.1 /usr/share/man/man1/avahi-discover.1 /usr/share/man/man1/avahi-publish.1 /usr/share/man/man1/avahi-resolve.1 /usr/share/man/man1/avahi-set-host-name.1 /usr/share/man/man1/bssh /usr/share/man/man1/bvnc (this is a link to /usr/share/man/man1/bssh) /usr/share/man/man5/avahi.hosts.5 /usr/share/man/man5/avahi.service.5 Imported Interfaces - libxml Committed PSARC 2001/175 Glib Committed LSARC 2006/462 pkg-config Volatile LSARC 2002/747 Python Volatile PSARC 2005/532 DBUS Volatile LSARC 2006/368 libdns-sd (Bonjour) Committed PSARC 2005/562 4.6. Doc Impact: Documentation will be provided as is standard with the Solaris OS - both in terms of developer references, man pages, and command line help. 4.7. Admin/Config Impact: 4.8. HA Impact: None. 4.9. I18N/L10N Impact: None. 4.10. Packaging & Delivery: This project is built, packaged and delivered as part of the current JDS desktop consolidation. 4.11. Security Impact: The process avahi-daemon-bridge-dsd will run as user daemon. No other known security impact. 4.12. Dependencies: LSARC 2006/462 - GNOME 2.16 LSARC 2002/747 - GNOME 2.0 pkg-config PSARC 2001/175 - libxml LSARC 2006/368 - D-BUS Message Bus System 5. Reference Documents: Avahi Community Website http://www.avahi.org Exisitng ARC cases LSARC 2006/462 - GNOME 2.16 PSARC 2005/562 - Multicast DNS and Service Discovery --Boundary_(ID_qwZu/jP+dcv8yBUrg9qptw)-- From John.Fischer@Sun.COM Wed Aug 15 10:47:34 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 l7FHlYpY016149 for ; Wed, 15 Aug 2007 10:47:34 -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 l7FHj5bs028201 for ; Wed, 15 Aug 2007 10:45:05 -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 l7FHj0uO022500 for ; Wed, 15 Aug 2007 10:45:00 -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 <0JMT00J01TAXNA00@fe-sfbay-10.sun.com> (original mail from John.Fischer@Sun.COM) for lsarc-ext@sac.sfbay.sun.com; Wed, 15 Aug 2007 10:45:00 -0700 (PDT) Received: from [129.150.12.240] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JMT00767TB0NKE0@fe-sfbay-10.sun.com>; Wed, 15 Aug 2007 10:45:00 -0700 (PDT) Date: Wed, 15 Aug 2007 10:44:07 -0700 From: John Fischer Subject: LSARC/2006/455 Avahi and libdaemon Sender: John.Fischer@Sun.COM To: lsarc-ext@sac.sfbay.sun.com, "Padraig O'Briain" Cc: psarc@Sun.COM Message-id: <46C33B67.7000904@sun.com> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_C8d6RH6vvSM9nIuNVlHjhA)" X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20051027 Status: RO Content-Length: 12914 This is a multi-part message in MIME format. --Boundary_(ID_C8d6RH6vvSM9nIuNVlHjhA) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT All, I am sponsoring this fast track for Padraig O'Briain from the JDS - Gnome team in Ireland. The case directory contains this proposal and man pages for the various commands. I have set the timer for Wednesday August 22nd, 2007. This project provides an alternative implementation to the Multicast DNS (mDNS) and Service Discovery project (aka Bonjour). This project is needed to provide support for various Gnome components. The project delivers the avahi client API. Instead of delivering the avahi daemon, which on linux and freebsd implements a mDNS stack, the project will change the avahi daemon to make calls to the Bonjour API so that it will use the Bonjour server. The project is requesting a Minor release of Solaris. Thanks, John --Boundary_(ID_C8d6RH6vvSM9nIuNVlHjhA) Content-type: text/plain; name=proposal.txt Content-transfer-encoding: 7BIT Content-disposition: inline; filename=proposal.txt 1. Introduction 1.1. Project/Component Working Name: Avahi and libdaemon 1.2. Name of Document Author/Supplier: Padraig O'Briain 1.3. The name of your business unit: JDS Desktop Engineering, Open Source Software, OPG 1.4. Email Aliases: 1.4.1. Responsible Manager: Leo Binchy 1.4.2. Responsible Engineer: Padraig O'Briain 1.4.3. Marketing Manager: Jeff Mc Meekin 1.4.4. Interest List: desktop-cteam@sun.com nwam-bonjour@sun.com bonjour-iteam@sun.com 2. Project Summary 2.1. Project Description: The Multicast DNS (mDNS) and Service Discovery project introduces DNS server-less link-local IP address resolution for ad-hoc networks and discovery of devices and services. See PSARC/2005/562. That project is based on Apple's implementation, a.k.a Bonjour. An alternative implementation is avahi, see www.avahi.org. Some GNOME components provide support for service registration and discovery using avahi. This project delivers the avahi client API. Instead of delivering the avahi daemon, which on linux and freebsd implements a mDNS stack, we will change the avahi daemon to make calls to the Bonjour API so that it will use the Bonjour server. Thus this project depends on PSARC/2005/562. libdaemon is a lightweight C library that eases the writing of UNIX daemons and is used by the avahi daemon. 4. Technical Description: 4.1. Details: Avahi consists of several parts: libavahi-common: a library containing some functions used by avahi clients and the avahi daemon itself. libavahi-core: A library implement service registration and discovery. libavahi-client: A minimal wrapper around the DBUS API to simplify its usage. It hides the DBUS internals completely. libavahi-glib: An adaptor for connecting avahi-client or avahi-core to a GLIB main loop. avahi-daemon: The avahi daemon makes use of libavahi-core to provide service registration and discovery to clients using the DBUS interface which is an IPC wrapper around the functions provided by avahi-core. We rename this to avahi-daemon-bridge-dsd so that it is clear that we are not delivering the standard avahi daemon. avahi-browse, avahi-discover, avahi-publish, avahi-resolve: Some command line utilities which use libavahi-client. See http://www.avahi.org/wiki/ArchitecturalOverview, which lists some other parts of avahi which we do not deliver. We make significant changes to avahi daemon and libavahi-core. Instead of implementing a mDNS/DNS-SD stack libavahi-core makes calls to the DNS Service Discovery API provided by Bonjour to register and discover services. As the avahi daemon does not provide service registration and discovery itself those portions related to being a mDNS server are omitted. libdaemon is a lightweight C library that eases the writing of UNIX daemons. It consists of the following parts: * A wrapper around fork() which does the correct daemonization procedure of a process * A wrapper around syslog() for simpler and compatible log output to Syslog or STDERR * An API for writing PID files * An API for serializing UNIX signals into a pipe for usage with select() or poll() * An API for running subprocesses with STDOUT and STDERR redirected to syslog. 4.2. Bug/RFE Number(s): N/A. 4.3. In Scope: The project team will integrate and support versions of Avahi continually throughout its life within the Solaris OS. The project team will mark the interfaces of Avahi as appropriate [detailed below] and work with other project teams to provide contracts of use, until such a stage where the technology can be considered as 'Committed' according to the interface taxonomy rules. 4.4. Out of Scope: Sun does not expect to be involved in the development and direction of avahi or libdaemon. Where possible, we will ship 'as is', with the changes to call Bonjour. Any developer changes will be pushed upstream where appropriate. 4.5. Interfaces: Exported Interfaces SUNWlibdaemon Uncommitted Package name for libdaemon Two packages SUNWlibdaemon and SUNWlibdaemon-devel are delivered. /usr/lib/libdaemon.so Volatile libdaemon C library /usr/lib/pkgconfig/libdaemon.pc pkgconfig file for Volatile libdaemon Volatile libdaemon API /usr/include/libdaemon/daemon.h /usr/include/libdaemon/dexec.h /usr/include/libdaemon/dfork.h /usr/include/libdaemon/dlog.h /usr/include/libdaemon/dnoblock.h /usr/include/libdaemon/dpid.h /usr/include/libdaemon/dsignal.h SUNWavahi-bridge-dsd Uncommitted Package name for avahi. Three packages SUNWavahi-bridge-dsd, SUNWavahi-bridge-dsd-devel and SUNWavahi-bridge-dsd-root are delivered. /etc/dbus-1/system.d/avahi-dbus.conf Configuration file for Volatile avahi DBUS messages. /etc/avahi/hosts Volatile address host mappings /etc/avahi/services/ssh.service Volatile Static service /var/run/avahi-daemon-bridge-dsd/pid Project Private PID file for avahi. svc:/system/avahi-bridge-dsd:default Volatile SMF service to start avahi-daemon-bridge-dsd. Volatile Avahi APIs. /usr/include/avahi-client/client.h /usr/include/avahi-client/lookup.h /usr/include/avahi-client/publish.h /usr/include/avahi-common/address.h /usr/include/avahi-common/address.h /usr/include/avahi-common/alternative.h /usr/include/avahi-common/cdecl.h /usr/include/avahi-common/defs.h /usr/include/avahi-common/domain.h /usr/include/avahi-common/error.h /usr/include/avahi-common/gccmacro.h /usr/include/avahi-common/llist.h /usr/include/avahi-common/malloc.h /usr/include/avahi-common/rlist.h /usr/include/avahi-common/simple-watch.h /usr/include/avahi-common/strlst.h /usr/include/avahi-common/thread-watch.h /usr/include/avahi-common/timeval.h /usr/include/avahi-common/watch.h /usr/include/avahi-core/core.h /usr/include/avahi-core/log.h /usr/include/avahi-core/lookup.h /usr/include/avahi-core/publish.h /usr/include/avahi-core/rr.h /usr/include/avahi-glib/glib-malloc.h /usr/include/avahi-glib/glib-watch.h /usr/lib/pkgconfig/avahi-client.pc pkgconfig files for /usr/lib/pkgconfig/avahi-core.pc avahi-core, avahi-client /usr/lib/pkgconfig/avahi-glib.pc and avahi-glib bindings. Volatile /usr/bin/avahi-browse Volatile Command line utilities /usr/bin/avahi-discover /usr/bin/bssh /usr/bin/bvnc (this is a link to /usr/bin/bssh) /usr/share/avahi/interfaces/avahi-discover.glade /usr/share/applications/avahi-discover.desktop /usr/bin/avahi-publish /usr/bin/avahi-resolve /usr/bin/avahi-set-host-name /usr/sbin/avahi-daemon-bridge-dsd Volatile Avahi server daemon. Volatile Avahi libraries /usr/lib/libavahi-client.so.3.2.0 /usr/lib/libavahi-common.so.3.4.2 /usr/lib/libavahi-core.so.4.0.4 /usr/lib/libavahi-glib.so.1.0.1 Volatile Avahi python bindings /usr/lib/python2.4/vendor-packages/avahi/ServiceTypeDatabase.py /usr/lib/python2.4/vendor-packages/avahi/SimpleGladeApp.py /usr/lib/python2.4/vendor-packages/avahi/SimpleGladeApp.pyc /usr/lib/python2.4/vendor-packages/avahi/__init__.py /usr/lib/python2.4/vendor-packages/avahi/__init__.pyc Volatile Avahi DBUS Introspection /usr/share/avahi/introspection/AddressResolver.introspect /usr/share/avahi/introspection/DomainBrowser.introspect /usr/share/avahi/introspection/EntryGroup.introspect /usr/share/avahi/introspection/HostNameResolver.introspect /usr/share/avahi/introspection/RecordBrowser.introspect /usr/share/avahi/introspection/Server.introspect /usr/share/avahi/introspection/ServiceBrowser.introspect /usr/share/avahi/introspection/ServiceResolver.introspect /usr/share/avahi/introspection/ServiceTypeBrowser.introspect Volatile Avahi Service Types database /usr/share/avahi/service-types /usr/share/avahi/service-types.DB.Dir /usr/share/avahi/service-types.db.pag /usr/share/avahi/avahi-service.dtd Volatile Man pages /usr/share/man/man1/avahi-browse.1 /usr/share/man/man1/avahi-daemon-bridge-dsd.1 /usr/share/man/man1/avahi-discover.1 /usr/share/man/man1/avahi-publish.1 /usr/share/man/man1/avahi-resolve.1 /usr/share/man/man1/avahi-set-host-name.1 /usr/share/man/man1/bssh /usr/share/man/man1/bvnc (this is a link to /usr/share/man/man1/bssh) /usr/share/man/man5/avahi.hosts.5 /usr/share/man/man5/avahi.service.5 Imported Interfaces - libxml Committed PSARC 2001/175 Glib Committed LSARC 2006/462 pkg-config Volatile LSARC 2002/747 Python Volatile PSARC 2005/532 DBUS Volatile LSARC 2006/368 libdns-sd (Bonjour) Committed PSARC 2005/562 4.6. Doc Impact: Documentation will be provided as is standard with the Solaris OS - both in terms of developer references, man pages, and command line help. 4.7. Admin/Config Impact: 4.8. HA Impact: None. 4.9. I18N/L10N Impact: None. 4.10. Packaging & Delivery: This project is built, packaged and delivered as part of the current JDS desktop consolidation. 4.11. Security Impact: The process avahi-daemon-bridge-dsd will run as user daemon. No other known security impact. 4.12. Dependencies: LSARC 2006/462 - GNOME 2.16 LSARC 2002/747 - GNOME 2.0 pkg-config PSARC 2001/175 - libxml LSARC 2006/368 - D-BUS Message Bus System 5. Reference Documents: Avahi Community Website http://www.avahi.org Exisitng ARC cases LSARC 2006/462 - GNOME 2.16 PSARC 2005/562 - Multicast DNS and Service Discovery --Boundary_(ID_C8d6RH6vvSM9nIuNVlHjhA)-- From jek3@sun.com Wed Aug 15 19:49:25 2007 Received: from jurassic-x4600.sfbay.sun.com (cretaceous [129.146.17.63] (may be forged)) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l7G2nPCm006236 for ; Wed, 15 Aug 2007 19:49:25 -0700 (PDT) Received: from [129.150.12.124] (vpn-129-150-12-124.SFBay.Sun.COM [129.150.12.124]) by jurassic-x4600.sfbay.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l7G2kvrq958306; Wed, 15 Aug 2007 19:46:57 -0700 (PDT) Message-ID: <46C3B9F4.2000805@sun.com> Date: Wed, 15 Aug 2007 16:44:04 -1000 From: Joseph Kowalski User-Agent: Thunderbird 1.5.0.5 (X11/20060925) MIME-Version: 1.0 To: John Fischer CC: lsarc-ext@sac.sfbay.sun.com, "Padraig O'Briain" , psarc@sun.com Subject: Re: LSARC/2006/455 Avahi and libdaemon References: <46C33B67.7000904@sun.com> In-Reply-To: <46C33B67.7000904@sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 572 John Fischer wrote: > I am sponsoring this fast track for Padraig O'Briain from the > JDS - Gnome team in Ireland. The case directory contains this > proposal and man pages for the various commands. I have set > the timer for Wednesday August 22nd, 2007. ... If I understand this right, libdaemon is a general purpose purpose library to make it easier to write daemons. It is Uncommitted. Shouldn't there be a definition of each of the Uncommitted interfaces exposed? Man pages would be nice, but perhaps something else as often suggested for "sfw" objects. - jek3 From sacadmin Wed Aug 15 19:49:30 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l7G2nUfe006248 for ; Wed, 15 Aug 2007 19:49:30 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l7G2l0PC001880; Wed, 15 Aug 2007 19:47:00 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JMU00H01IEAJJ00@nwk-avmta-2.sfbay.sun.com>; Wed, 15 Aug 2007 19:46:58 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JMU00E85IEA0C80@nwk-avmta-2.sfbay.sun.com>; Wed, 15 Aug 2007 19:46:58 -0700 (PDT) Received: from [129.150.12.124] (vpn-129-150-12-124.SFBay.Sun.COM [129.150.12.124]) by jurassic-x4600.sfbay.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l7G2kvrq958306; Wed, 15 Aug 2007 19:46:57 -0700 (PDT) Date: Wed, 15 Aug 2007 16:44:04 -1000 From: Joseph Kowalski Subject: Re: LSARC/2006/455 Avahi and libdaemon In-reply-to: <46C33B67.7000904@sun.com> To: John Fischer Cc: lsarc-ext@sac.sfbay.sun.com, "Padraig O'Briain" , psarc@sun.com Message-id: <46C3B9F4.2000805@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <46C33B67.7000904@sun.com> User-Agent: Thunderbird 1.5.0.5 (X11/20060925) Status: RO Content-Length: 572 John Fischer wrote: > I am sponsoring this fast track for Padraig O'Briain from the > JDS - Gnome team in Ireland. The case directory contains this > proposal and man pages for the various commands. I have set > the timer for Wednesday August 22nd, 2007. ... If I understand this right, libdaemon is a general purpose purpose library to make it easier to write daemons. It is Uncommitted. Shouldn't there be a definition of each of the Uncommitted interfaces exposed? Man pages would be nice, but perhaps something else as often suggested for "sfw" objects. - jek3 From sacadmin Thu Aug 16 00:40:19 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l7G7eIaW010523 for ; Thu, 16 Aug 2007 00:40:19 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l7G7bjet012024 for <@sunmail2sca.sfbay.sun.com:psarc@sun.com>; Thu, 16 Aug 2007 15:37:49 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JMU00A07VUZ3Y00@nwk-avmta-2.sfbay.sun.com> for psarc@sun.com (ORCPT psarc@sun.com); Thu, 16 Aug 2007 00:37:47 -0700 (PDT) Received: from gmp-ea-fw-1.sun.com ([129.156.42.5]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JMU00NQQVUY3990@nwk-avmta-2.sfbay.sun.com> for psarc@sun.com (ORCPT psarc@sun.com); Thu, 16 Aug 2007 00:37:47 -0700 (PDT) Received: from d1-emea-10.sun.com (d1-emea-10.sun.com [192.18.2.120]) by gmp-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l7G7bjbC027996 for ; Thu, 16 Aug 2007 07:37:45 +0000 (GMT) Received: from conversion-daemon.d1-emea-10.sun.com by d1-emea-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JMU00A01VSM7800@d1-emea-10.sun.com> (original mail from Padraig.Obriain@Sun.COM) for psarc@sun.com (ORCPT psarc@sun.com); Thu, 16 Aug 2007 08:37:45 +0100 (BST) Received: from [129.156.234.22] by d1-emea-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JMU0068ZVUXSQ0W@d1-emea-10.sun.com>; Thu, 16 Aug 2007 08:37:45 +0100 (BST) Date: Thu, 16 Aug 2007 08:17:05 +0100 From: "Padraig O'Briain" Subject: Re: LSARC/2006/455 Avahi and libdaemon In-reply-to: <46C3B9F4.2000805@sun.com> Sender: Padraig.Obriain@sun.com To: Joseph Kowalski Cc: John Fischer , lsarc-ext@sac.sfbay.sun.com, psarc@sun.com Message-id: <46C3F9F1.5070308@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <46C33B67.7000904@sun.com> <46C3B9F4.2000805@sun.com> User-Agent: Thunderbird 2.0b2 (X11/20070129) Status: RO Content-Length: 820 Joseph Kowalski wrote: > John Fischer wrote: >> I am sponsoring this fast track for Padraig O'Briain from the >> JDS - Gnome team in Ireland. The case directory contains this >> proposal and man pages for the various commands. I have set >> the timer for Wednesday August 22nd, 2007. > ... > > If I understand this right, libdaemon is a general purpose purpose > library to make it easier to write daemons. It is Uncommitted. > Shouldn't there be a definition of each of the Uncommitted > interfaces exposed? Man pages would be nice, but perhaps > something else as often suggested for "sfw" objects. > > - jek3 > libdaemon does not have any man pages. The only reason for delivering libdaemon is that it is used by avahi. It is not intended to make libdaemon available for any other projects to use. Padraig From Padraig.Obriain@Sun.COM Thu Aug 16 00:40:20 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 l7G7eKHv010527 for ; Thu, 16 Aug 2007 00:40:20 -0700 (PDT) Received: from gmp-ea-fw-1.sun.com (gmpes-gis-mail-2.UK.Sun.COM [129.156.42.6]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id l7G7bpMZ013157 for ; Thu, 16 Aug 2007 00:37:52 -0700 (PDT) Received: from d1-emea-10.sun.com ([192.18.2.120]) by gmp-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l7G7bj9s018087 for ; Thu, 16 Aug 2007 07:37:45 GMT Received: from conversion-daemon.d1-emea-10.sun.com by d1-emea-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JMU00A01VSM7800@d1-emea-10.sun.com> (original mail from Padraig.Obriain@Sun.COM) for lsarc-ext@sac.sfbay.sun.com; Thu, 16 Aug 2007 08:37:45 +0100 (BST) Received: from [129.156.234.22] by d1-emea-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JMU0068ZVUXSQ0W@d1-emea-10.sun.com>; Thu, 16 Aug 2007 08:37:45 +0100 (BST) Date: Thu, 16 Aug 2007 08:17:05 +0100 From: "Padraig O'Briain" Subject: Re: LSARC/2006/455 Avahi and libdaemon In-reply-to: <46C3B9F4.2000805@sun.com> Sender: Padraig.Obriain@Sun.COM To: Joseph Kowalski Cc: John Fischer , lsarc-ext@sac.sfbay.sun.com, psarc@Sun.COM Message-id: <46C3F9F1.5070308@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <46C33B67.7000904@sun.com> <46C3B9F4.2000805@sun.com> User-Agent: Thunderbird 2.0b2 (X11/20070129) Status: RO Content-Length: 820 Joseph Kowalski wrote: > John Fischer wrote: >> I am sponsoring this fast track for Padraig O'Briain from the >> JDS - Gnome team in Ireland. The case directory contains this >> proposal and man pages for the various commands. I have set >> the timer for Wednesday August 22nd, 2007. > ... > > If I understand this right, libdaemon is a general purpose purpose > library to make it easier to write daemons. It is Uncommitted. > Shouldn't there be a definition of each of the Uncommitted > interfaces exposed? Man pages would be nice, but perhaps > something else as often suggested for "sfw" objects. > > - jek3 > libdaemon does not have any man pages. The only reason for delivering libdaemon is that it is used by avahi. It is not intended to make libdaemon available for any other projects to use. Padraig From Brian.Cameron@Sun.COM Thu Aug 16 08:27:10 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 l7GFRASB020535 for ; Thu, 16 Aug 2007 08:27:10 -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 l7GFOixG021739 for ; Thu, 16 Aug 2007 08:24:44 -0700 (PDT) Received: from fe-amer-03.sun.com ([192.18.108.177]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l7GFOh5b015282 for ; Thu, 16 Aug 2007 15:24:43 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 <0JMV00901HAEB800@mail-amer.sun.com> (original mail from Brian.Cameron@Sun.COM) for lsarc-ext@sac.sfbay.sun.com; Thu, 16 Aug 2007 09:24:43 -0600 (MDT) Received: from [10.255.135.41] ([208.54.7.183]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JMV0073KHH3NEN2@mail-amer.sun.com>; Thu, 16 Aug 2007 09:24:43 -0600 (MDT) Date: Thu, 16 Aug 2007 10:23:06 -0500 From: Brian Cameron Subject: Re: LSARC/2006/455 Avahi and libdaemon In-reply-to: <46C3F9F1.5070308@sun.com> Sender: Brian.Cameron@Sun.COM To: "Padraig O'Briain" Cc: Joseph Kowalski , John Fischer , lsarc-ext@sac.sfbay.sun.com, psarc@Sun.COM Message-id: <46C46BDA.9060508@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <46C33B67.7000904@sun.com> <46C3B9F4.2000805@sun.com> <46C3F9F1.5070308@sun.com> User-Agent: Thunderbird 2.0.0.5 (X11/20070730) Status: RO Content-Length: 1442 Padraig: My understanding of Sun manpage policy is that all libraries should have manpages, if only to describe that they are Uncommitted in the ATTRIBUTES section and not to be used. The fact that there are many non-Committed JDS libraries that don't meet this policy is probably not a good excuse either, though probably a better one. One thing worth mentioning in JDS library manpages is whether the library is in the GNOME Platform. If so, the community provides ABI stability. For libraries non in the Platform, it's probably good to mention this as an extra warning. Brian > Joseph Kowalski wrote: >> John Fischer wrote: >>> I am sponsoring this fast track for Padraig O'Briain from the >>> JDS - Gnome team in Ireland. The case directory contains this >>> proposal and man pages for the various commands. I have set >>> the timer for Wednesday August 22nd, 2007. >> ... >> >> If I understand this right, libdaemon is a general purpose purpose >> library to make it easier to write daemons. It is Uncommitted. >> Shouldn't there be a definition of each of the Uncommitted >> interfaces exposed? Man pages would be nice, but perhaps >> something else as often suggested for "sfw" objects. >> >> - jek3 >> > > libdaemon does not have any man pages. > > The only reason for delivering libdaemon is that it is used by avahi. > > It is not intended to make libdaemon available for any other projects to > use. > > Padraig From sacadmin Thu Aug 16 08:27:12 2007 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l7GFRB5D020539 for ; Thu, 16 Aug 2007 08:27:12 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l7GFOU83031235 for <@sunmail2sca.sfbay.sun.com:psarc@sun.com>; Thu, 16 Aug 2007 09:24:32 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JMV0091BHH8WK00@nwk-avmta-2.sfbay.sun.com> for psarc@sun.com (ORCPT psarc@sun.com); Thu, 16 Aug 2007 08:24:44 -0700 (PDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JMV007IPHH7IP80@nwk-avmta-2.sfbay.sun.com> for psarc@sun.com (ORCPT psarc@sun.com); Thu, 16 Aug 2007 08:24:44 -0700 (PDT) Received: from fe-amer-03.sun.com ([192.18.108.177]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l7GFOhsH009805 for ; Thu, 16 Aug 2007 15:24:43 +0000 (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 <0JMV00901HAEB800@mail-amer.sun.com> (original mail from Brian.Cameron@Sun.COM) for psarc@sun.com (ORCPT psarc@sun.com); Thu, 16 Aug 2007 09:24:43 -0600 (MDT) Received: from [10.255.135.41] ([208.54.7.183]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JMV0073KHH3NEN2@mail-amer.sun.com>; Thu, 16 Aug 2007 09:24:43 -0600 (MDT) Date: Thu, 16 Aug 2007 10:23:06 -0500 From: Brian Cameron Subject: Re: LSARC/2006/455 Avahi and libdaemon In-reply-to: <46C3F9F1.5070308@sun.com> Sender: Brian.Cameron@sun.com To: "Padraig O'Briain" Cc: Joseph Kowalski , John Fischer , lsarc-ext@sac.sfbay.sun.com, psarc@sun.com Message-id: <46C46BDA.9060508@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <46C33B67.7000904@sun.com> <46C3B9F4.2000805@sun.com> <46C3F9F1.5070308@sun.com> User-Agent: Thunderbird 2.0.0.5 (X11/20070730) Status: RO Content-Length: 1442 Padraig: My understanding of Sun manpage policy is that all libraries should have manpages, if only to describe that they are Uncommitted in the ATTRIBUTES section and not to be used. The fact that there are many non-Committed JDS libraries that don't meet this policy is probably not a good excuse either, though probably a better one. One thing worth mentioning in JDS library manpages is whether the library is in the GNOME Platform. If so, the community provides ABI stability. For libraries non in the Platform, it's probably good to mention this as an extra warning. Brian > Joseph Kowalski wrote: >> John Fischer wrote: >>> I am sponsoring this fast track for Padraig O'Briain from the >>> JDS - Gnome team in Ireland. The case directory contains this >>> proposal and man pages for the various commands. I have set >>> the timer for Wednesday August 22nd, 2007. >> ... >> >> If I understand this right, libdaemon is a general purpose purpose >> library to make it easier to write daemons. It is Uncommitted. >> Shouldn't there be a definition of each of the Uncommitted >> interfaces exposed? Man pages would be nice, but perhaps >> something else as often suggested for "sfw" objects. >> >> - jek3 >> > > libdaemon does not have any man pages. > > The only reason for delivering libdaemon is that it is used by avahi. > > It is not intended to make libdaemon available for any other projects to > use. > > Padraig From Keith.Bierman@Sun.COM Thu Aug 16 08:31:34 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 l7GFVYwW020562 for ; Thu, 16 Aug 2007 08:31:34 -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 l7GFT7lW000199 for ; Thu, 16 Aug 2007 08:29:07 -0700 (PDT) Received: from fe-amer-01.sun.com ([192.18.108.175]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l7GFT7Zo010418 for ; Thu, 16 Aug 2007 15:29:07 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 <0JMV00L01HBR6X00@mail-amer.sun.com> (original mail from Keith.Bierman@Sun.COM) for lsarc-ext@sac.sfbay.sun.com; Thu, 16 Aug 2007 09:29:07 -0600 (MDT) Received: from [192.168.100.25] ([67.165.243.234]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JMV007POHOIMQ76@mail-amer.sun.com>; Thu, 16 Aug 2007 09:29:07 -0600 (MDT) Date: Thu, 16 Aug 2007 09:29:05 -0600 From: Keith Bierman Subject: Re: LSARC/2006/455 Avahi and libdaemon In-reply-to: <46C46BDA.9060508@sun.com> Sender: Keith.Bierman@Sun.COM To: Brian Cameron Cc: "Padraig O'Briain" , Joseph Kowalski , John Fischer , lsarc-ext@sac.sfbay.sun.com, psarc@Sun.COM Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.752.2) Content-type: text/plain; format=flowed; delsp=yes; charset=US-ASCII Content-transfer-encoding: 7BIT References: <46C33B67.7000904@sun.com> <46C3B9F4.2000805@sun.com> <46C3F9F1.5070308@sun.com> <46C46BDA.9060508@sun.com> Status: RO Content-Length: 1551 On Aug 16, 2007, at 9:23 AM, Brian Cameron wrote: > > Padraig: > > My understanding of Sun manpage policy is that all libraries > should have manpages, if only to describe that they are Uncommitted > in the ATTRIBUTES section and not to be used. The fact that there > are many non-Committed JDS libraries that don't meet this policy is > probably not a good excuse either, though probably a better one. > > One thing worth mentioning in JDS library manpages is whether the > library is in the GNOME Platform. If so, the community provides > ABI stability. For libraries non in the Platform, it's probably > good to mention this as an extra warning. > > Brian > If the intention is that it's used by this project only, isn't it "project private" and not UNCOMMITTED? Keith H. Bierman keith.bierman@Sun.COM | khbkhb@gmail.com Strategic Engagement Team | sun IM: khb AIM: kbiermank 5430 Nassau Circle East | 650-352-4432 voice+fax Cherry Hills Village, CO 80113 | sun internal 68207 http://blogs.sun.com/khb | 303-997-2749 Copyright 2007 ------------------------------------------------------------ From sacadmin Thu Aug 16 08:31:38 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l7GFVbD4020574 for ; Thu, 16 Aug 2007 08:31:38 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l7GFT85r007379 for <@sunmail2sca.sfbay.sun.com:psarc@sun.com>; Thu, 16 Aug 2007 16:29:10 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JMV00A03HOK1X00@nwk-avmta-2.sfbay.sun.com> for psarc@sun.com (ORCPT psarc@sun.com); Thu, 16 Aug 2007 08:29:08 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JMV007JVHOJIM80@nwk-avmta-2.sfbay.sun.com> for psarc@sun.com (ORCPT psarc@sun.com); Thu, 16 Aug 2007 08:29:07 -0700 (PDT) Received: from fe-amer-01.sun.com ([192.18.108.175]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l7GFT7un016969 for ; Thu, 16 Aug 2007 15:29:07 +0000 (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 <0JMV00L01HBR6X00@mail-amer.sun.com> (original mail from Keith.Bierman@Sun.COM) for psarc@sun.com (ORCPT psarc@sun.com); Thu, 16 Aug 2007 09:29:07 -0600 (MDT) Received: from [192.168.100.25] ([67.165.243.234]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JMV007POHOIMQ76@mail-amer.sun.com>; Thu, 16 Aug 2007 09:29:07 -0600 (MDT) Date: Thu, 16 Aug 2007 09:29:05 -0600 From: Keith Bierman Subject: Re: LSARC/2006/455 Avahi and libdaemon In-reply-to: <46C46BDA.9060508@sun.com> Sender: Keith.Bierman@Sun.COM To: Brian Cameron Cc: "Padraig O'Briain" , Joseph Kowalski , John Fischer , lsarc-ext@sac.sfbay.sun.com, psarc@Sun.COM Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.752.2) Content-type: text/plain; format=flowed; delsp=yes; charset=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <46C33B67.7000904@sun.com> <46C3B9F4.2000805@sun.com> <46C3F9F1.5070308@sun.com> <46C46BDA.9060508@sun.com> Status: RO Content-Length: 1551 On Aug 16, 2007, at 9:23 AM, Brian Cameron wrote: > > Padraig: > > My understanding of Sun manpage policy is that all libraries > should have manpages, if only to describe that they are Uncommitted > in the ATTRIBUTES section and not to be used. The fact that there > are many non-Committed JDS libraries that don't meet this policy is > probably not a good excuse either, though probably a better one. > > One thing worth mentioning in JDS library manpages is whether the > library is in the GNOME Platform. If so, the community provides > ABI stability. For libraries non in the Platform, it's probably > good to mention this as an extra warning. > > Brian > If the intention is that it's used by this project only, isn't it "project private" and not UNCOMMITTED? Keith H. Bierman keith.bierman@Sun.COM | khbkhb@gmail.com Strategic Engagement Team | sun IM: khb AIM: kbiermank 5430 Nassau Circle East | 650-352-4432 voice+fax Cherry Hills Village, CO 80113 | sun internal 68207 http://blogs.sun.com/khb | 303-997-2749 Copyright 2007 ------------------------------------------------------------ From carlsonj@phorcys.east.sun.com Thu Aug 16 08:38:35 2007 Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l7GFcZ4V020641 for ; Thu, 16 Aug 2007 08:38:35 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l7GFa8VJ105495; Thu, 16 Aug 2007 11:36:08 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.1+Sun/8.14.1/Submit) id l7GFa8D5105492; Thu, 16 Aug 2007 11:36:08 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18116.28392.505249.903322@gargle.gargle.HOWL> Date: Thu, 16 Aug 2007 11:36:08 -0400 From: James Carlson To: Brian Cameron Cc: "Padraig O'Briain" , Joseph Kowalski , John Fischer , lsarc-ext@sac.sfbay.sun.com, psarc@Sun.COM Subject: Re: LSARC/2006/455 Avahi and libdaemon In-Reply-To: <46C46BDA.9060508@sun.com> References: <46C33B67.7000904@sun.com> <46C3B9F4.2000805@sun.com> <46C3F9F1.5070308@sun.com> <46C46BDA.9060508@sun.com> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 886 Brian Cameron writes: > My understanding of Sun manpage policy is that all libraries > should have manpages, if only to describe that they are Uncommitted > in the ATTRIBUTES section and not to be used. No, if it's intended as "Private," as this one seems to be, then *by definition* it must not have man pages. In that case, it should be shipped as libdaemon.so.1 (not libdaemon.so, as the case materials seem to have), and it should omit any compilation symlink and associated header files. If it's meant to be used by multiple projects, and not just this one, then it may well need a much closer look and higher commitment, which would require a man page. -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From sacadmin Thu Aug 16 08:38:44 2007 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l7GFciQE020653 for ; Thu, 16 Aug 2007 08:38:44 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l7GFZrOE036216; Thu, 16 Aug 2007 09:35:59 -0600 (MDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JMV00F0XI0BWQ00@brm-avmta-1.central.sun.com>; Thu, 16 Aug 2007 09:36:11 -0600 (MDT) Received: from phorcys.east.sun.com ([129.148.174.143]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JMV00F8RI09CP10@brm-avmta-1.central.sun.com>; Thu, 16 Aug 2007 09:36:10 -0600 (MDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l7GFa8VJ105495; Thu, 16 Aug 2007 11:36:08 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.1+Sun/8.14.1/Submit) id l7GFa8D5105492; Thu, 16 Aug 2007 11:36:08 -0400 (EDT) Date: Thu, 16 Aug 2007 11:36:08 -0400 From: James Carlson Subject: Re: LSARC/2006/455 Avahi and libdaemon In-reply-to: <46C46BDA.9060508@sun.com> To: Brian Cameron Cc: "Padraig O'Briain" , Joseph Kowalski , John Fischer , lsarc-ext@sac.sfbay.sun.com, psarc@sun.com Message-id: <18116.28392.505249.903322@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <46C33B67.7000904@sun.com> <46C3B9F4.2000805@sun.com> <46C3F9F1.5070308@sun.com> <46C46BDA.9060508@sun.com> Status: RO Content-Length: 886 Brian Cameron writes: > My understanding of Sun manpage policy is that all libraries > should have manpages, if only to describe that they are Uncommitted > in the ATTRIBUTES section and not to be used. No, if it's intended as "Private," as this one seems to be, then *by definition* it must not have man pages. In that case, it should be shipped as libdaemon.so.1 (not libdaemon.so, as the case materials seem to have), and it should omit any compilation symlink and associated header files. If it's meant to be used by multiple projects, and not just this one, then it may well need a much closer look and higher commitment, which would require a man page. -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From sacadmin Thu Aug 16 08:52:34 2007 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l7GFqYDG020982 for ; Thu, 16 Aug 2007 08:52:34 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l7GFns2R041894 for <@sunmail2sca.sfbay.sun.com:psarc@sun.com>; Thu, 16 Aug 2007 09:49:55 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JMV00A17INITX00@nwk-avmta-2.sfbay.sun.com> for psarc@sun.com (ORCPT psarc@sun.com); Thu, 16 Aug 2007 08:50:06 -0700 (PDT) Received: from gmp-ea-fw-1.sun.com ([129.156.42.6]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JMV007XHINGIMB0@nwk-avmta-2.sfbay.sun.com> for psarc@sun.com (ORCPT psarc@sun.com); Thu, 16 Aug 2007 08:50:05 -0700 (PDT) Received: from d1-emea-10.sun.com ([192.18.2.120]) by gmp-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l7GFo36t010248 for ; Thu, 16 Aug 2007 15:50:03 +0000 (GMT) Received: from conversion-daemon.d1-emea-10.sun.com by d1-emea-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JMV00G01IJX1K00@d1-emea-10.sun.com> (original mail from Padraig.Obriain@Sun.COM) for psarc@sun.com (ORCPT psarc@sun.com); Thu, 16 Aug 2007 16:50:03 +0100 (BST) Received: from [129.156.234.22] by d1-emea-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JMV006U8INFSQUW@d1-emea-10.sun.com>; Thu, 16 Aug 2007 16:50:03 +0100 (BST) Date: Thu, 16 Aug 2007 16:29:22 +0100 From: "Padraig O'Briain" Subject: Re: LSARC/2006/455 Avahi and libdaemon In-reply-to: <18116.28392.505249.903322@gargle.gargle.HOWL> Sender: Padraig.Obriain@sun.com To: James Carlson Cc: Brian Cameron , Joseph Kowalski , John Fischer , lsarc-ext@sac.sfbay.sun.com, psarc@sun.com Message-id: <46C46D52.3070007@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <46C33B67.7000904@sun.com> <46C3B9F4.2000805@sun.com> <46C3F9F1.5070308@sun.com> <46C46BDA.9060508@sun.com> <18116.28392.505249.903322@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0b2 (X11/20070129) Status: RO Content-Length: 873 It is my intention that libdaemon.so should be Private. The library name is actually libdaemon.so.0.3.0. This was an error on my part. Padraig James Carlson wrote: > Brian Cameron writes: > >> My understanding of Sun manpage policy is that all libraries >> should have manpages, if only to describe that they are Uncommitted >> in the ATTRIBUTES section and not to be used. >> > > No, if it's intended as "Private," as this one seems to be, then *by > definition* it must not have man pages. > > In that case, it should be shipped as libdaemon.so.1 (not > libdaemon.so, as the case materials seem to have), and it should omit > any compilation symlink and associated header files. > > If it's meant to be used by multiple projects, and not just this one, > then it may well need a much closer look and higher commitment, which > would require a man page. > > From Padraig.Obriain@Sun.COM Thu Aug 16 08:52:36 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 l7GFqacZ020986 for ; Thu, 16 Aug 2007 08:52:36 -0700 (PDT) Received: from gmp-ea-fw-1.sun.com (gmpes-gis-mail-1.UK.Sun.COM [129.156.42.5]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l7GFo9fe007787 for ; Thu, 16 Aug 2007 08:50:10 -0700 (PDT) Received: from d1-emea-10.sun.com (d1-emea-10.sun.com [192.18.2.120]) by gmp-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l7GFo3YC020191 for ; Thu, 16 Aug 2007 15:50:04 GMT Received: from conversion-daemon.d1-emea-10.sun.com by d1-emea-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JMV00G01IJX1K00@d1-emea-10.sun.com> (original mail from Padraig.Obriain@Sun.COM) for lsarc-ext@sac.sfbay.sun.com; Thu, 16 Aug 2007 16:50:03 +0100 (BST) Received: from [129.156.234.22] by d1-emea-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JMV006U8INFSQUW@d1-emea-10.sun.com>; Thu, 16 Aug 2007 16:50:03 +0100 (BST) Date: Thu, 16 Aug 2007 16:29:22 +0100 From: "Padraig O'Briain" Subject: Re: LSARC/2006/455 Avahi and libdaemon In-reply-to: <18116.28392.505249.903322@gargle.gargle.HOWL> Sender: Padraig.Obriain@Sun.COM To: James Carlson Cc: Brian Cameron , Joseph Kowalski , John Fischer , lsarc-ext@sac.sfbay.sun.com, psarc@Sun.COM Message-id: <46C46D52.3070007@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <46C33B67.7000904@sun.com> <46C3B9F4.2000805@sun.com> <46C3F9F1.5070308@sun.com> <46C46BDA.9060508@sun.com> <18116.28392.505249.903322@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0b2 (X11/20070129) Status: RO Content-Length: 873 It is my intention that libdaemon.so should be Private. The library name is actually libdaemon.so.0.3.0. This was an error on my part. Padraig James Carlson wrote: > Brian Cameron writes: > >> My understanding of Sun manpage policy is that all libraries >> should have manpages, if only to describe that they are Uncommitted >> in the ATTRIBUTES section and not to be used. >> > > No, if it's intended as "Private," as this one seems to be, then *by > definition* it must not have man pages. > > In that case, it should be shipped as libdaemon.so.1 (not > libdaemon.so, as the case materials seem to have), and it should omit > any compilation symlink and associated header files. > > If it's meant to be used by multiple projects, and not just this one, > then it may well need a much closer look and higher commitment, which > would require a man page. > > From Brian.Cameron@Sun.COM Thu Aug 16 08:53:42 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 l7GFrgCX021009 for ; Thu, 16 Aug 2007 08:53:42 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id l7GFpFtL015436 for ; Thu, 16 Aug 2007 08:51:15 -0700 (PDT) Received: from fe-amer-05.sun.com ([192.18.108.179]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l7GFpFhI024942 for ; Thu, 16 Aug 2007 15:51:15 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 <0JMV00401IEE3A00@mail-amer.sun.com> (original mail from Brian.Cameron@Sun.COM) for lsarc-ext@sac.sfbay.sun.com; Thu, 16 Aug 2007 09:51:15 -0600 (MDT) Received: from [10.255.135.41] ([208.54.7.183]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JMV003Z0IPCLS0A@mail-amer.sun.com>; Thu, 16 Aug 2007 09:51:15 -0600 (MDT) Date: Thu, 16 Aug 2007 10:49:40 -0500 From: Brian Cameron Subject: Re: LSARC/2006/455 Avahi and libdaemon In-reply-to: <18116.28392.505249.903322@gargle.gargle.HOWL> Sender: Brian.Cameron@Sun.COM To: James Carlson Cc: "Padraig O'Briain" , Joseph Kowalski , John Fischer , lsarc-ext@sac.sfbay.sun.com, psarc@Sun.COM Message-id: <46C47214.5050406@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <46C33B67.7000904@sun.com> <46C3B9F4.2000805@sun.com> <46C3F9F1.5070308@sun.com> <46C46BDA.9060508@sun.com> <18116.28392.505249.903322@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.5 (X11/20070730) Status: RO Content-Length: 2399 James: I think the complication with libraries such as libnotify is that they are free software projects, so while Sun can say "anything we ship that uses this will come from the JDS team so it is project private", this doesn't mean that 3rd parties or others in the free software community might not write stuff that uses it. It isn't really private since the source code is freely available, as are ABI docs, websites, mail list archive discussions, etc. So this sort of interface falls in the fuzzy ground between Uncommitted, External, and Private. From Sun's perspective, we can consider it Private. From a realistic perspective, it is Uncommitted. That's my take. The advantage of providing a manpage is that it provides help to developers wanting to work with the library in the free software community. Such a manpage should probably explain that the library isn't too stable, and perhaps encourage people to engage with the community to make it more stable if this is desired. Isn't OpenSolaris trying to encourage developers to adopt it's platform? Quality manpages and good documentation are probably the sort of thing that attracts developers, no? The feeling that your distro cares, you know. Though perhaps Sun doesn't want to invest too much time/effort into supporting free software desktop developers, specifically. Also, some argue that people don't read manpages for desktop applications since most user's interact with the desktop only via the UI. I don't know. I like manpages, and I think they have value. So, over the years, I've worked quite a bit on them. Many of the GNOME manpages we ship have my name on them, but I don't want to write them all myself. Brian > Brian Cameron writes: >> My understanding of Sun manpage policy is that all libraries >> should have manpages, if only to describe that they are Uncommitted >> in the ATTRIBUTES section and not to be used. > > No, if it's intended as "Private," as this one seems to be, then *by > definition* it must not have man pages. > > In that case, it should be shipped as libdaemon.so.1 (not > libdaemon.so, as the case materials seem to have), and it should omit > any compilation symlink and associated header files. > > If it's meant to be used by multiple projects, and not just this one, > then it may well need a much closer look and higher commitment, which > would require a man page. > From sacadmin Thu Aug 16 08:53:45 2007 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l7GFrjdN021021 for ; Thu, 16 Aug 2007 08:53:45 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l7GFp34F042487 for <@sunmail2sca.sfbay.sun.com:psarc@sun.com>; Thu, 16 Aug 2007 09:51:06 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JMV00L0LIPGGU00@nwk-avmta-1.sfbay.Sun.COM> for psarc@sun.com (ORCPT psarc@sun.com); Thu, 16 Aug 2007 08:51:16 -0700 (PDT) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JMV0088FIPFFEB0@nwk-avmta-1.sfbay.Sun.COM> for psarc@sun.com (ORCPT psarc@sun.com); Thu, 16 Aug 2007 08:51:16 -0700 (PDT) Received: from fe-amer-05.sun.com ([192.18.108.179]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l7GFpFpE023330 for ; Thu, 16 Aug 2007 15:51:15 +0000 (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 <0JMV00401IEE3A00@mail-amer.sun.com> (original mail from Brian.Cameron@Sun.COM) for psarc@sun.com (ORCPT psarc@sun.com); Thu, 16 Aug 2007 09:51:15 -0600 (MDT) Received: from [10.255.135.41] ([208.54.7.183]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JMV003Z0IPCLS0A@mail-amer.sun.com>; Thu, 16 Aug 2007 09:51:15 -0600 (MDT) Date: Thu, 16 Aug 2007 10:49:40 -0500 From: Brian Cameron Subject: Re: LSARC/2006/455 Avahi and libdaemon In-reply-to: <18116.28392.505249.903322@gargle.gargle.HOWL> Sender: Brian.Cameron@sun.com To: James Carlson Cc: "Padraig O'Briain" , Joseph Kowalski , John Fischer , lsarc-ext@sac.sfbay.sun.com, psarc@sun.com Message-id: <46C47214.5050406@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <46C33B67.7000904@sun.com> <46C3B9F4.2000805@sun.com> <46C3F9F1.5070308@sun.com> <46C46BDA.9060508@sun.com> <18116.28392.505249.903322@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.5 (X11/20070730) Status: RO Content-Length: 2399 James: I think the complication with libraries such as libnotify is that they are free software projects, so while Sun can say "anything we ship that uses this will come from the JDS team so it is project private", this doesn't mean that 3rd parties or others in the free software community might not write stuff that uses it. It isn't really private since the source code is freely available, as are ABI docs, websites, mail list archive discussions, etc. So this sort of interface falls in the fuzzy ground between Uncommitted, External, and Private. From Sun's perspective, we can consider it Private. From a realistic perspective, it is Uncommitted. That's my take. The advantage of providing a manpage is that it provides help to developers wanting to work with the library in the free software community. Such a manpage should probably explain that the library isn't too stable, and perhaps encourage people to engage with the community to make it more stable if this is desired. Isn't OpenSolaris trying to encourage developers to adopt it's platform? Quality manpages and good documentation are probably the sort of thing that attracts developers, no? The feeling that your distro cares, you know. Though perhaps Sun doesn't want to invest too much time/effort into supporting free software desktop developers, specifically. Also, some argue that people don't read manpages for desktop applications since most user's interact with the desktop only via the UI. I don't know. I like manpages, and I think they have value. So, over the years, I've worked quite a bit on them. Many of the GNOME manpages we ship have my name on them, but I don't want to write them all myself. Brian > Brian Cameron writes: >> My understanding of Sun manpage policy is that all libraries >> should have manpages, if only to describe that they are Uncommitted >> in the ATTRIBUTES section and not to be used. > > No, if it's intended as "Private," as this one seems to be, then *by > definition* it must not have man pages. > > In that case, it should be shipped as libdaemon.so.1 (not > libdaemon.so, as the case materials seem to have), and it should omit > any compilation symlink and associated header files. > > If it's meant to be used by multiple projects, and not just this one, > then it may well need a much closer look and higher commitment, which > would require a man page. > From Keith.Bierman@Sun.COM Thu Aug 16 09:02:04 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 l7GG24xQ021505 for ; Thu, 16 Aug 2007 09:02:04 -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 l7GFxbxw019729 for ; Thu, 16 Aug 2007 08:59:37 -0700 (PDT) Received: from fe-amer-05.sun.com ([192.18.108.179]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l7GFxboP027948 for ; Thu, 16 Aug 2007 15:59:37 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 <0JMV00601IXTBG00@mail-amer.sun.com> (original mail from Keith.Bierman@Sun.COM) for lsarc-ext@sac.sfbay.sun.com; Thu, 16 Aug 2007 09:59:37 -0600 (MDT) Received: from [192.168.100.25] ([67.165.243.234]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JMV00ADDJ37DYW4@mail-amer.sun.com>; Thu, 16 Aug 2007 09:59:32 -0600 (MDT) Date: Thu, 16 Aug 2007 09:59:30 -0600 From: Keith Bierman Subject: Re: LSARC/2006/455 Avahi and libdaemon In-reply-to: <46C47214.5050406@sun.com> Sender: Keith.Bierman@Sun.COM To: Brian Cameron Cc: James Carlson , "Padraig O'Briain" , Joseph Kowalski , John Fischer , lsarc-ext@sac.sfbay.sun.com, psarc@Sun.COM Message-id: <38AF2557-393D-456E-B1C2-A1F24CE469A2@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.752.2) Content-type: text/plain; format=flowed; delsp=yes; charset=US-ASCII Content-transfer-encoding: 7BIT References: <46C33B67.7000904@sun.com> <46C3B9F4.2000805@sun.com> <46C3F9F1.5070308@sun.com> <46C46BDA.9060508@sun.com> <18116.28392.505249.903322@gargle.gargle.HOWL> <46C47214.5050406@sun.com> Status: RO Content-Length: 1158 On Aug 16, 2007, at 9:49 AM, Brian Cameron wrote: > > James: > > It > isn't really private since the source code is freely available, as > are ABI docs, websites, mail list archive discussions, etc. Even if it's our code, we publish it. OpenSolaris is open... If we say it's "Private" it means *we* are making no representations about it. Folks that use it are on their own. Keith H. Bierman keith.bierman@Sun.COM | khbkhb@gmail.com Strategic Engagement Team | sun IM: khb AIM: kbiermank 5430 Nassau Circle East | 650-352-4432 voice+fax Cherry Hills Village, CO 80113 | sun internal 68207 http://blogs.sun.com/khb | 303-997-2749 Copyright 2007 ------------------------------------------------------------ From sacadmin Thu Aug 16 09:02:06 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l7GG26dG021515 for ; Thu, 16 Aug 2007 09:02:06 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l7GFxZhL025705 for <@sunmail2sca.sfbay.sun.com:psarc@sun.com>; Thu, 16 Aug 2007 08:59:40 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JMV00H3FJ3F6K00@brm-avmta-1.central.sun.com> for psarc@sun.com (ORCPT psarc@sun.com); Thu, 16 Aug 2007 09:59:39 -0600 (MDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JMV00F09J3DCP30@brm-avmta-1.central.sun.com> for psarc@sun.com (ORCPT psarc@sun.com); Thu, 16 Aug 2007 09:59:38 -0600 (MDT) Received: from fe-amer-05.sun.com ([192.18.108.179]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l7GFxb5g004362 for ; Thu, 16 Aug 2007 15:59:37 +0000 (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 <0JMV00601IXTBG00@mail-amer.sun.com> (original mail from Keith.Bierman@Sun.COM) for psarc@sun.com (ORCPT psarc@sun.com); Thu, 16 Aug 2007 09:59:37 -0600 (MDT) Received: from [192.168.100.25] ([67.165.243.234]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JMV00ADDJ37DYW4@mail-amer.sun.com>; Thu, 16 Aug 2007 09:59:32 -0600 (MDT) Date: Thu, 16 Aug 2007 09:59:30 -0600 From: Keith Bierman Subject: Re: LSARC/2006/455 Avahi and libdaemon In-reply-to: <46C47214.5050406@sun.com> Sender: Keith.Bierman@sun.com To: Brian Cameron Cc: James Carlson , "Padraig O'Briain" , Joseph Kowalski , John Fischer , lsarc-ext@sac.sfbay.sun.com, psarc@sun.com Message-id: <38AF2557-393D-456E-B1C2-A1F24CE469A2@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.752.2) Content-type: text/plain; format=flowed; delsp=yes; charset=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <46C33B67.7000904@sun.com> <46C3B9F4.2000805@sun.com> <46C3F9F1.5070308@sun.com> <46C46BDA.9060508@sun.com> <18116.28392.505249.903322@gargle.gargle.HOWL> <46C47214.5050406@sun.com> Status: RO Content-Length: 1158 On Aug 16, 2007, at 9:49 AM, Brian Cameron wrote: > > James: > > It > isn't really private since the source code is freely available, as > are ABI docs, websites, mail list archive discussions, etc. Even if it's our code, we publish it. OpenSolaris is open... If we say it's "Private" it means *we* are making no representations about it. Folks that use it are on their own. Keith H. Bierman keith.bierman@Sun.COM | khbkhb@gmail.com Strategic Engagement Team | sun IM: khb AIM: kbiermank 5430 Nassau Circle East | 650-352-4432 voice+fax Cherry Hills Village, CO 80113 | sun internal 68207 http://blogs.sun.com/khb | 303-997-2749 Copyright 2007 ------------------------------------------------------------ From carlsonj@phorcys.east.sun.com Thu Aug 16 09:06:35 2007 Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l7GG6YLr021631 for ; Thu, 16 Aug 2007 09:06:35 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l7GG48jc105798; Thu, 16 Aug 2007 12:04:08 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.1+Sun/8.14.1/Submit) id l7GG48MI105795; Thu, 16 Aug 2007 12:04:08 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18116.30072.317576.64537@gargle.gargle.HOWL> Date: Thu, 16 Aug 2007 12:04:08 -0400 From: James Carlson To: Brian Cameron Cc: John Fischer , lsarc-ext@sac.sfbay.sun.com, Joseph Kowalski , "Padraig O'Briain" , psarc@Sun.COM Subject: Re: LSARC/2006/455 Avahi and libdaemon In-Reply-To: <46C47214.5050406@sun.com> References: <46C33B67.7000904@sun.com> <46C3B9F4.2000805@sun.com> <46C3F9F1.5070308@sun.com> <46C46BDA.9060508@sun.com> <18116.28392.505249.903322@gargle.gargle.HOWL> <46C47214.5050406@sun.com> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 2498 Brian Cameron writes: > I think the complication with libraries such as libnotify is that > they are free software projects, so while Sun can say "anything we > ship that uses this will come from the JDS team so it is project > private", this doesn't mean that 3rd parties or others in the > free software community might not write stuff that uses it. It > isn't really private since the source code is freely available, as > are ABI docs, websites, mail list archive discussions, etc. I agree that we need to pay heed to the intent of the author. However, if all that we deliver is the .so.1 file without the compilation symlink and without the header files needed to use the library, users aren't going to run into this very easily. We can always make it Committed in the future if it turns out that there really is more than just this one consumer. > So this sort of interface falls in the fuzzy ground between Uncommitted, > External, and Private. From Sun's perspective, we can consider it > Private. From a realistic perspective, it is Uncommitted. That's my > take. It's hard for me to determine what the libdaemon author's intent was, or whether it's in fact used anywhere outside of this project, or the general [Linux] community "feeling" about this library. If it's not used elsewhere, then there's no reason to clutter the system with documentation on stuff that's just never used and would serve only to confuse. > Isn't OpenSolaris trying to encourage developers to adopt it's platform? Of course. That doesn't mean turning it into a dumping ground. > Quality manpages and good documentation are probably the sort of thing that > attracts developers, no? Absolutely. We can't do a half-baked job here. It should be either a good first-class citizen on its own merits, or should be buried deeply where it won't hurt anyone. The project team seems to assert that it belongs in the latter category. Are you sure it's in the former? It's been around for a while, but I can't see much that has decided to use it. The web page says ifplugd, Avahi, ivam2, Nautilus-Share, and aeswepd. Of those, only Avahi seems to have any applicability to any future version of [Open]Solaris. The rest are seem to be duplicates of existing features/projects. -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From sacadmin Thu Aug 16 09:06:40 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l7GG6eS3021643 for ; Thu, 16 Aug 2007 09:06:40 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l7GG4BNl027505; Thu, 16 Aug 2007 09:04:11 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JMV00B0BJAYE600@nwk-avmta-2.sfbay.sun.com>; Thu, 16 Aug 2007 09:04:10 -0700 (PDT) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JMV007JMJAXINE0@nwk-avmta-2.sfbay.sun.com>; Thu, 16 Aug 2007 09:04:09 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l7GG48jc105798; Thu, 16 Aug 2007 12:04:08 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.1+Sun/8.14.1/Submit) id l7GG48MI105795; Thu, 16 Aug 2007 12:04:08 -0400 (EDT) Date: Thu, 16 Aug 2007 12:04:08 -0400 From: James Carlson Subject: Re: LSARC/2006/455 Avahi and libdaemon In-reply-to: <46C47214.5050406@sun.com> To: Brian Cameron Cc: John Fischer , lsarc-ext@sac.sfbay.sun.com, Joseph Kowalski , "Padraig O'Briain" , psarc@sun.com Message-id: <18116.30072.317576.64537@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <46C33B67.7000904@sun.com> <46C3B9F4.2000805@sun.com> <46C3F9F1.5070308@sun.com> <46C46BDA.9060508@sun.com> <18116.28392.505249.903322@gargle.gargle.HOWL> <46C47214.5050406@sun.com> Status: RO Content-Length: 2498 Brian Cameron writes: > I think the complication with libraries such as libnotify is that > they are free software projects, so while Sun can say "anything we > ship that uses this will come from the JDS team so it is project > private", this doesn't mean that 3rd parties or others in the > free software community might not write stuff that uses it. It > isn't really private since the source code is freely available, as > are ABI docs, websites, mail list archive discussions, etc. I agree that we need to pay heed to the intent of the author. However, if all that we deliver is the .so.1 file without the compilation symlink and without the header files needed to use the library, users aren't going to run into this very easily. We can always make it Committed in the future if it turns out that there really is more than just this one consumer. > So this sort of interface falls in the fuzzy ground between Uncommitted, > External, and Private. From Sun's perspective, we can consider it > Private. From a realistic perspective, it is Uncommitted. That's my > take. It's hard for me to determine what the libdaemon author's intent was, or whether it's in fact used anywhere outside of this project, or the general [Linux] community "feeling" about this library. If it's not used elsewhere, then there's no reason to clutter the system with documentation on stuff that's just never used and would serve only to confuse. > Isn't OpenSolaris trying to encourage developers to adopt it's platform? Of course. That doesn't mean turning it into a dumping ground. > Quality manpages and good documentation are probably the sort of thing that > attracts developers, no? Absolutely. We can't do a half-baked job here. It should be either a good first-class citizen on its own merits, or should be buried deeply where it won't hurt anyone. The project team seems to assert that it belongs in the latter category. Are you sure it's in the former? It's been around for a while, but I can't see much that has decided to use it. The web page says ifplugd, Avahi, ivam2, Nautilus-Share, and aeswepd. Of those, only Avahi seems to have any applicability to any future version of [Open]Solaris. The rest are seem to be duplicates of existing features/projects. -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From Brian.Cameron@Sun.COM Thu Aug 16 09:13:05 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 l7GGD4GB021880 for ; Thu, 16 Aug 2007 09:13:04 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id l7GGAccn027123 for ; Thu, 16 Aug 2007 09:10:38 -0700 (PDT) Received: from fe-amer-01.sun.com ([192.18.108.175]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l7GGAcrF006030 for ; Thu, 16 Aug 2007 16:10:38 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 <0JMV00701JFQO100@mail-amer.sun.com> (original mail from Brian.Cameron@Sun.COM) for lsarc-ext@sac.sfbay.sun.com; Thu, 16 Aug 2007 10:10:38 -0600 (MDT) Received: from [10.255.135.41] ([208.54.7.183]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JMV00433JLNDMA9@mail-amer.sun.com>; Thu, 16 Aug 2007 10:10:37 -0600 (MDT) Date: Thu, 16 Aug 2007 11:09:03 -0500 From: Brian Cameron Subject: Re: LSARC/2006/455 Avahi and libdaemon In-reply-to: <18116.30072.317576.64537@gargle.gargle.HOWL> Sender: Brian.Cameron@Sun.COM To: James Carlson Cc: John Fischer , lsarc-ext@sac.sfbay.sun.com, Joseph Kowalski , "Padraig O'Briain" , psarc@Sun.COM Message-id: <46C4769F.80407@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <46C33B67.7000904@sun.com> <46C3B9F4.2000805@sun.com> <46C3F9F1.5070308@sun.com> <46C46BDA.9060508@sun.com> <18116.28392.505249.903322@gargle.gargle.HOWL> <46C47214.5050406@sun.com> <18116.30072.317576.64537@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.5 (X11/20070730) Status: RO Content-Length: 1543 James: > I agree that we need to pay heed to the intent of the author. > > However, if all that we deliver is the .so.1 file without the > compilation symlink and without the header files needed to use the > library, users aren't going to run into this very easily. > > We can always make it Committed in the future if it turns out that > there really is more than just this one consumer. Indeed. >> Quality manpages and good documentation are probably the sort of thing that >> attracts developers, no? > > Absolutely. We can't do a half-baked job here. It should be either a > good first-class citizen on its own merits, or should be buried > deeply where it won't hurt anyone. > > The project team seems to assert that it belongs in the latter > category. Are you sure it's in the former? It's been around for a > while, but I can't see much that has decided to use it. The web page > says ifplugd, Avahi, ivam2, Nautilus-Share, and aeswepd. > > Of those, only Avahi seems to have any applicability to any future > version of [Open]Solaris. The rest are seem to be duplicates of > existing features/projects. This is up for Padraig to specify. I just was complaining that the JDS team (and probably other teams at Sun) probably needs to take a bit more care when thinking about whether we want/need manpages. Just because we consider something private, doesn't mean we shouldn't ship a manpage when the interfaces are public. This is really a case-by-case issue when dealing with free software. Just my opinion. Brian From sacadmin Thu Aug 16 09:13:08 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l7GGD7Yb021892 for ; Thu, 16 Aug 2007 09:13:07 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l7GGAf2o023513 for <@sunmail2sca.sfbay.sun.com:psarc@sun.com>; Thu, 16 Aug 2007 09:10:41 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JMV00B01JLQME00@nwk-avmta-2.sfbay.sun.com> for psarc@sun.com (ORCPT psarc@sun.com); Thu, 16 Aug 2007 09:10:39 -0700 (PDT) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JMV00BCAJLQIW00@nwk-avmta-2.sfbay.sun.com> for psarc@sun.com (ORCPT psarc@sun.com); Thu, 16 Aug 2007 09:10:38 -0700 (PDT) Received: from fe-amer-01.sun.com ([192.18.108.175]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l7GGAc06004560 for ; Thu, 16 Aug 2007 16:10:38 +0000 (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 <0JMV00701JFQO100@mail-amer.sun.com> (original mail from Brian.Cameron@Sun.COM) for psarc@sun.com (ORCPT psarc@sun.com); Thu, 16 Aug 2007 10:10:38 -0600 (MDT) Received: from [10.255.135.41] ([208.54.7.183]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JMV00433JLNDMA9@mail-amer.sun.com>; Thu, 16 Aug 2007 10:10:37 -0600 (MDT) Date: Thu, 16 Aug 2007 11:09:03 -0500 From: Brian Cameron Subject: Re: LSARC/2006/455 Avahi and libdaemon In-reply-to: <18116.30072.317576.64537@gargle.gargle.HOWL> Sender: Brian.Cameron@sun.com To: James Carlson Cc: John Fischer , lsarc-ext@sac.sfbay.sun.com, Joseph Kowalski , "Padraig O'Briain" , psarc@sun.com Message-id: <46C4769F.80407@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <46C33B67.7000904@sun.com> <46C3B9F4.2000805@sun.com> <46C3F9F1.5070308@sun.com> <46C46BDA.9060508@sun.com> <18116.28392.505249.903322@gargle.gargle.HOWL> <46C47214.5050406@sun.com> <18116.30072.317576.64537@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.5 (X11/20070730) Status: RO Content-Length: 1543 James: > I agree that we need to pay heed to the intent of the author. > > However, if all that we deliver is the .so.1 file without the > compilation symlink and without the header files needed to use the > library, users aren't going to run into this very easily. > > We can always make it Committed in the future if it turns out that > there really is more than just this one consumer. Indeed. >> Quality manpages and good documentation are probably the sort of thing that >> attracts developers, no? > > Absolutely. We can't do a half-baked job here. It should be either a > good first-class citizen on its own merits, or should be buried > deeply where it won't hurt anyone. > > The project team seems to assert that it belongs in the latter > category. Are you sure it's in the former? It's been around for a > while, but I can't see much that has decided to use it. The web page > says ifplugd, Avahi, ivam2, Nautilus-Share, and aeswepd. > > Of those, only Avahi seems to have any applicability to any future > version of [Open]Solaris. The rest are seem to be duplicates of > existing features/projects. This is up for Padraig to specify. I just was complaining that the JDS team (and probably other teams at Sun) probably needs to take a bit more care when thinking about whether we want/need manpages. Just because we consider something private, doesn't mean we shouldn't ship a manpage when the interfaces are public. This is really a case-by-case issue when dealing with free software. Just my opinion. Brian From John.Fischer@sun.com Thu Aug 16 09:15:52 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l7GGFqLI022029 for ; Thu, 16 Aug 2007 09:15:52 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l7GGDNBY024283 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Thu, 16 Aug 2007 09:13:25 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JMV00H0DJQCWC00@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 16 Aug 2007 10:13:24 -0600 (MDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JMV00FUGJQACU30@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 16 Aug 2007 10:13:22 -0600 (MDT) 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 l7GGDM7A015522 for ; Thu, 16 Aug 2007 09:13:22 -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 <0JMV00201JCU0V00@fe-sfbay-09.sun.com> (original mail from John.Fischer@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 16 Aug 2007 09:13:22 -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 <0JMV004QQJQ8MJA0@fe-sfbay-09.sun.com>; Thu, 16 Aug 2007 09:13:20 -0700 (PDT) Date: Thu, 16 Aug 2007 09:13:19 -0700 From: John Fischer Subject: Re: LSARC/2006/455 Avahi and libdaemon In-reply-to: <38AF2557-393D-456E-B1C2-A1F24CE469A2@sun.com> Sender: John.Fischer@sun.com To: lsarc@sac.sfbay.sun.com Cc: "Padraig O'Briain" , PSARC-ext@sun.com Message-id: <46C4779F.9040709@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 X-PMX-Version: 5.2.0.264296 References: <46C33B67.7000904@sun.com> <46C3B9F4.2000805@sun.com> <46C3F9F1.5070308@sun.com> <46C46BDA.9060508@sun.com> <18116.28392.505249.903322@gargle.gargle.HOWL> <46C47214.5050406@sun.com> <38AF2557-393D-456E-B1C2-A1F24CE469A2@sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20051027 Status: RO Content-Length: 1378 All, For some reason lsarc-ext is not working correctly. I have changed the Cc line to be psarc-ext and lsarc only. Thanks, John Keith Bierman wrote: > > On Aug 16, 2007, at 9:49 AM, Brian Cameron wrote: > >> >> James: >> >> It >> isn't really private since the source code is freely available, as >> are ABI docs, websites, mail list archive discussions, etc. > > > Even if it's our code, we publish it. OpenSolaris is open... > > If we say it's "Private" it means *we* are making no representations > about it. Folks that use it are on their own. > > > Keith H. Bierman keith.bierman@Sun.COM | khbkhb@gmail.com > Strategic Engagement Team | sun IM: khb AIM: kbiermank > 5430 Nassau Circle East | 650-352-4432 voice+fax > Cherry Hills Village, CO 80113 | sun internal 68207 > http://blogs.sun.com/khb | 303-997-2749 > Copyright 2007 > ------------------------------------------------------------ > > > > From sacadmin Thu Aug 16 09:15:53 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 l7GGFrYn022033 for ; Thu, 16 Aug 2007 09:15:53 -0700 (PDT) Received: from sca-es-mail-2.sun.com (sca-es-mail-2.Sun.COM [192.18.43.133]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id l7GGDRXW028394 for ; Thu, 16 Aug 2007 09:13:27 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l7GGDM9m027049 for ; Thu, 16 Aug 2007 09:13:22 -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 <0JMV00201JCU0V00@fe-sfbay-09.sun.com> (original mail from John.Fischer@Sun.COM) for lsarc@sac.sfbay.sun.com; Thu, 16 Aug 2007 09:13:22 -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 <0JMV004QQJQ8MJA0@fe-sfbay-09.sun.com>; Thu, 16 Aug 2007 09:13:20 -0700 (PDT) Date: Thu, 16 Aug 2007 09:13:19 -0700 From: John Fischer Subject: Re: LSARC/2006/455 Avahi and libdaemon In-reply-to: <38AF2557-393D-456E-B1C2-A1F24CE469A2@sun.com> Sender: John.Fischer@Sun.COM To: lsarc@sac.sfbay.sun.com Cc: "Padraig O'Briain" , PSARC-ext@Sun.COM Message-id: <46C4779F.9040709@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: <46C33B67.7000904@sun.com> <46C3B9F4.2000805@sun.com> <46C3F9F1.5070308@sun.com> <46C46BDA.9060508@sun.com> <18116.28392.505249.903322@gargle.gargle.HOWL> <46C47214.5050406@sun.com> <38AF2557-393D-456E-B1C2-A1F24CE469A2@sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20051027 Status: RO Content-Length: 1378 All, For some reason lsarc-ext is not working correctly. I have changed the Cc line to be psarc-ext and lsarc only. Thanks, John Keith Bierman wrote: > > On Aug 16, 2007, at 9:49 AM, Brian Cameron wrote: > >> >> James: >> >> It >> isn't really private since the source code is freely available, as >> are ABI docs, websites, mail list archive discussions, etc. > > > Even if it's our code, we publish it. OpenSolaris is open... > > If we say it's "Private" it means *we* are making no representations > about it. Folks that use it are on their own. > > > Keith H. Bierman keith.bierman@Sun.COM | khbkhb@gmail.com > Strategic Engagement Team | sun IM: khb AIM: kbiermank > 5430 Nassau Circle East | 650-352-4432 voice+fax > Cherry Hills Village, CO 80113 | sun internal 68207 > http://blogs.sun.com/khb | 303-997-2749 > Copyright 2007 > ------------------------------------------------------------ > > > > From jek3@sun.com Thu Aug 16 09:47:16 2007 Received: from jurassic-x4600.sfbay.sun.com (cretaceous [129.146.17.59]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l7GGlGfq023044 for ; Thu, 16 Aug 2007 09:47:16 -0700 (PDT) Received: from [129.150.12.124] (vpn-129-150-12-124.SFBay.Sun.COM [129.150.12.124]) by jurassic-x4600.sfbay.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l7GGinjC148846; Thu, 16 Aug 2007 09:44:49 -0700 (PDT) Message-ID: <46C47E52.90105@sun.com> Date: Thu, 16 Aug 2007 06:41:54 -1000 From: Joseph Kowalski User-Agent: Thunderbird 1.5.0.5 (X11/20060925) MIME-Version: 1.0 To: "Padraig O'Briain" CC: John Fischer , lsarc-ext@sac.sfbay.sun.com, psarc@sun.com Subject: Re: LSARC/2006/455 Avahi and libdaemon References: <46C33B67.7000904@sun.com> <46C3B9F4.2000805@sun.com> <46C3F9F1.5070308@sun.com> In-Reply-To: <46C3F9F1.5070308@sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 1062 Padraig O'Briain wrote: > Joseph Kowalski wrote: >> John Fischer wrote: >>> I am sponsoring this fast track for Padraig O'Briain from the >>> JDS - Gnome team in Ireland. The case directory contains this >>> proposal and man pages for the various commands. I have set >>> the timer for Wednesday August 22nd, 2007. >> ... >> >> If I understand this right, libdaemon is a general purpose purpose >> library to make it easier to write daemons. It is Uncommitted. >> Shouldn't there be a definition of each of the Uncommitted >> interfaces exposed? Man pages would be nice, but perhaps >> something else as often suggested for "sfw" objects. >> >> - jek3 >> > > libdaemon does not have any man pages. > > The only reason for delivering libdaemon is that it is used by avahi. > > It is not intended to make libdaemon available for any other projects > to use. > > Padraig PSARC/LSARC might have a different opinion, but maybe not. :-) What is clear is that you assign a taxonomy or Uncommitted to libdaemon. What you describe is "Project Private". - jek3 From sacadmin Thu Aug 16 09:47:25 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l7GGlPNU023082 for ; Thu, 16 Aug 2007 09:47:25 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l7GGinI5012729; Fri, 17 Aug 2007 00:44:54 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JMV00J0DL6RLZ00@brm-avmta-1.central.sun.com>; Thu, 16 Aug 2007 10:44:51 -0600 (MDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JMV00FTHL6QCQ50@brm-avmta-1.central.sun.com>; Thu, 16 Aug 2007 10:44:50 -0600 (MDT) Received: from [129.150.12.124] (vpn-129-150-12-124.SFBay.Sun.COM [129.150.12.124]) by jurassic-x4600.sfbay.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l7GGinjC148846; Thu, 16 Aug 2007 09:44:49 -0700 (PDT) Date: Thu, 16 Aug 2007 06:41:54 -1000 From: Joseph Kowalski Subject: Re: LSARC/2006/455 Avahi and libdaemon In-reply-to: <46C3F9F1.5070308@sun.com> To: "Padraig O'Briain" Cc: John Fischer , lsarc-ext@sac.sfbay.sun.com, psarc@sun.com Message-id: <46C47E52.90105@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <46C33B67.7000904@sun.com> <46C3B9F4.2000805@sun.com> <46C3F9F1.5070308@sun.com> User-Agent: Thunderbird 1.5.0.5 (X11/20060925) Status: RO Content-Length: 1062 Padraig O'Briain wrote: > Joseph Kowalski wrote: >> John Fischer wrote: >>> I am sponsoring this fast track for Padraig O'Briain from the >>> JDS - Gnome team in Ireland. The case directory contains this >>> proposal and man pages for the various commands. I have set >>> the timer for Wednesday August 22nd, 2007. >> ... >> >> If I understand this right, libdaemon is a general purpose purpose >> library to make it easier to write daemons. It is Uncommitted. >> Shouldn't there be a definition of each of the Uncommitted >> interfaces exposed? Man pages would be nice, but perhaps >> something else as often suggested for "sfw" objects. >> >> - jek3 >> > > libdaemon does not have any man pages. > > The only reason for delivering libdaemon is that it is used by avahi. > > It is not intended to make libdaemon available for any other projects > to use. > > Padraig PSARC/LSARC might have a different opinion, but maybe not. :-) What is clear is that you assign a taxonomy or Uncommitted to libdaemon. What you describe is "Project Private". - jek3 From jek3@sun.com Thu Aug 16 10:31:41 2007 Received: from jurassic-x4600.sfbay.sun.com (cretaceous [129.146.17.59]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l7GHVfLX024861 for ; Thu, 16 Aug 2007 10:31:41 -0700 (PDT) Received: from [129.150.12.124] (vpn-129-150-12-124.SFBay.Sun.COM [129.150.12.124]) by jurassic-x4600.sfbay.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l7GHTDl5180724; Thu, 16 Aug 2007 10:29:14 -0700 (PDT) Message-ID: <46C488BA.5070208@sun.com> Date: Thu, 16 Aug 2007 07:26:18 -1000 From: Joseph Kowalski User-Agent: Thunderbird 1.5.0.5 (X11/20060925) MIME-Version: 1.0 To: Brian Cameron CC: James Carlson , "Padraig O'Briain" , John Fischer , lsarc-ext@sac.sfbay.sun.com, psarc@sun.com Subject: Re: LSARC/2006/455 Avahi and libdaemon References: <46C33B67.7000904@sun.com> <46C3B9F4.2000805@sun.com> <46C3F9F1.5070308@sun.com> <46C46BDA.9060508@sun.com> <18116.28392.505249.903322@gargle.gargle.HOWL> <46C47214.5050406@sun.com> In-Reply-To: <46C47214.5050406@sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 474 Brian Cameron wrote: > So this sort of interface falls in the fuzzy ground between Uncommitted, > External, and Private. From Sun's perspective, we can consider it > Private. From a realistic perspective, it is Uncommitted. That's my > take. This is why I said the LSARC/PSARC may have a different perspective. They should make sure that this isn't "fuzzy". I (we) are well aware of the "Private to Sun, public to FOSS" issue. The poster-boy for this is nscp. - jek3 From sacadmin Thu Aug 16 10:31:47 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l7GHVlGj024873 for ; Thu, 16 Aug 2007 10:31:47 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l7GHTAiE024260; Thu, 16 Aug 2007 18:29:15 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JMV00G07N8R3K00@nwk-avmta-2.sfbay.sun.com>; Thu, 16 Aug 2007 10:29:15 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JMV00BOFN8QIU80@nwk-avmta-2.sfbay.sun.com>; Thu, 16 Aug 2007 10:29:14 -0700 (PDT) Received: from [129.150.12.124] (vpn-129-150-12-124.SFBay.Sun.COM [129.150.12.124]) by jurassic-x4600.sfbay.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l7GHTDl5180724; Thu, 16 Aug 2007 10:29:14 -0700 (PDT) Date: Thu, 16 Aug 2007 07:26:18 -1000 From: Joseph Kowalski Subject: Re: LSARC/2006/455 Avahi and libdaemon In-reply-to: <46C47214.5050406@sun.com> To: Brian Cameron Cc: James Carlson , "Padraig O'Briain" , John Fischer , lsarc-ext@sac.sfbay.sun.com, psarc@sun.com Message-id: <46C488BA.5070208@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <46C33B67.7000904@sun.com> <46C3B9F4.2000805@sun.com> <46C3F9F1.5070308@sun.com> <46C46BDA.9060508@sun.com> <18116.28392.505249.903322@gargle.gargle.HOWL> <46C47214.5050406@sun.com> User-Agent: Thunderbird 1.5.0.5 (X11/20060925) Status: RO Content-Length: 474 Brian Cameron wrote: > So this sort of interface falls in the fuzzy ground between Uncommitted, > External, and Private. From Sun's perspective, we can consider it > Private. From a realistic perspective, it is Uncommitted. That's my > take. This is why I said the LSARC/PSARC may have a different perspective. They should make sure that this isn't "fuzzy". I (we) are well aware of the "Private to Sun, public to FOSS" issue. The poster-boy for this is nscp. - jek3 From Padraig.Obriain@Sun.COM Mon Aug 20 16:29:48 2007 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca [129.145.154.35]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l7KNTmO6000952 for ; Mon, 20 Aug 2007 16:29:48 -0700 (PDT) Received: from gmp-ea-fw-1.sun.com (gmpes-gis-mail-2.UK.Sun.COM [129.156.42.6]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l7K7aRq0014425 for ; Mon, 20 Aug 2007 00:36:28 -0700 (PDT) Received: from d1-emea-10.sun.com ([192.18.2.120]) by gmp-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l7K7aLeK027854 for ; Mon, 20 Aug 2007 07:36:22 GMT Received: from conversion-daemon.d1-emea-10.sun.com by d1-emea-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JN200601AE9HW00@d1-emea-10.sun.com> (original mail from Padraig.Obriain@Sun.COM) for lsarc-ext@sac.sfbay.sun.com; Mon, 20 Aug 2007 08:36:21 +0100 (BST) Received: from [129.156.234.22] by d1-emea-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JN2006RNAGKSDC0@d1-emea-10.sun.com>; Mon, 20 Aug 2007 08:36:21 +0100 (BST) Date: Mon, 20 Aug 2007 08:15:30 +0100 From: "Padraig O'Briain" Subject: Re: LSARC/2006/455 Avahi and libdaemon In-reply-to: <46C46D52.3070007@sun.com> Sender: Padraig.Obriain@Sun.COM To: James Carlson Cc: Brian Cameron , Joseph Kowalski , John Fischer , lsarc-ext@sac.sfbay.sun.com, psarc@Sun.COM Message-id: <46C93F92.1010904@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <46C33B67.7000904@sun.com> <46C3B9F4.2000805@sun.com> <46C3F9F1.5070308@sun.com> <46C46BDA.9060508@sun.com> <18116.28392.505249.903322@gargle.gargle.HOWL> <46C46D52.3070007@sun.com> User-Agent: Thunderbird 2.0b2 (X11/20070129) Status: RO Content-Length: 1446 I have spoken to Laca about this and RE's policy is to always deliver the include files for a library. Someone might want to build or develop a 3rd party app that uses libdaemon. If we don't ship the headers, the only option they have is find the same version that is shipped with Solaris and extract the headers for themselves. Worse, if they pick the latest version and they to use those headers with the old library there is likely to be problems. So interface classification should be Volatile. Padraig Padraig O'Briain wrote: > It is my intention that libdaemon.so should be Private. > > The library name is actually libdaemon.so.0.3.0. > This was an error on my part. > > Padraig > > James Carlson wrote: >> Brian Cameron writes: >> >>> My understanding of Sun manpage policy is that all libraries >>> should have manpages, if only to describe that they are Uncommitted >>> in the ATTRIBUTES section and not to be used. >>> >> >> No, if it's intended as "Private," as this one seems to be, then *by >> definition* it must not have man pages. >> >> In that case, it should be shipped as libdaemon.so.1 (not >> libdaemon.so, as the case materials seem to have), and it should omit >> any compilation symlink and associated header files. >> >> If it's meant to be used by multiple projects, and not just this one, >> then it may well need a much closer look and higher commitment, which >> would require a man page. >> >> > From sacadmin Mon Aug 20 16:38:26 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l7KNcQlQ001733 for ; Mon, 20 Aug 2007 16:38:26 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l7KCk5gG016852; Mon, 20 Aug 2007 05:46:06 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JN200F01OST5L00@nwk-avmta-2.sfbay.sun.com>; Mon, 20 Aug 2007 05:46:05 -0700 (PDT) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JN2008NROSS78D0@nwk-avmta-2.sfbay.sun.com>; Mon, 20 Aug 2007 05:46:05 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l7KCk4RV101741; Mon, 20 Aug 2007 08:46:04 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.1+Sun/8.14.1/Submit) id l7KCk3JS101738; Mon, 20 Aug 2007 08:46:04 -0400 (EDT) Date: Mon, 20 Aug 2007 08:46:03 -0400 From: James Carlson Subject: Re: LSARC/2006/455 Avahi and libdaemon In-reply-to: <46C93F92.1010904@sun.com> To: "Padraig O'Briain" Cc: Brian Cameron , Joseph Kowalski , John Fischer , lsarc-ext@sac.sfbay.sun.com, psarc@sun.com Message-id: <18121.36107.765134.495767@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <46C33B67.7000904@sun.com> <46C3B9F4.2000805@sun.com> <46C3F9F1.5070308@sun.com> <46C46BDA.9060508@sun.com> <18116.28392.505249.903322@gargle.gargle.HOWL> <46C46D52.3070007@sun.com> <46C93F92.1010904@sun.com> Status: RO Content-Length: 1522 Padraig O'Briain writes: > I have spoken to Laca about this and RE's policy is to always deliver > the include files for a library. I think the wires are getting crossed somewhere, because the fact that it's a library alone does not trigger the need to deliver anything other than the .so.1 file. The actual policy is here: http://www.opensolaris.org/os/community/arc/policies/libraries/ See W3. (It's also somewhere on sac.sfbay ... but that system is dead right now.) The key issue is whether this is intended to be private or not. > Someone might want to build or develop a 3rd party app that uses > libdaemon. If we don't ship the headers, the only option they have is > find the same version that is shipped with Solaris and extract the > headers for themselves. Worse, if they pick the latest version and they > to use those headers with the old library there is likely to be problems. No, that's not the only option. They can also download the source themselves and compile a new version of the library, and use that _instead_. Mixing and matching header files and other bits related to an undocumented library would indeed be a bad idea, but it's certainly not the only option if the library is private. > So interface classification should be Volatile. OK. That works. -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From David.Comay@Sun.COM Mon Aug 20 16:41:35 2007 Received: from izimbra.SFBay.Sun.COM (izimbra [129.146.226.141]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l7KNfZUo001767 for ; Mon, 20 Aug 2007 16:41:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by izimbra.SFBay.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id l7KNd3kf314034; Mon, 20 Aug 2007 16:39:04 -0700 (PDT) Date: Mon, 20 Aug 2007 16:39:03 -0700 (PDT) From: David.Comay@Sun.COM Sender: comay@izimbra.sfbay.sun.com To: "Padraig O'Briain" cc: James Carlson , John Fischer , lsarc-ext@sac.sfbay.sun.com, psarc@Sun.COM, Joseph Kowalski , Brian Cameron Subject: Re: LSARC/2006/455 Avahi and libdaemon In-Reply-To: <46C93F92.1010904@sun.com> Message-ID: References: <46C33B67.7000904@sun.com> <46C3B9F4.2000805@sun.com> <46C3F9F1.5070308@sun.com> <46C46BDA.9060508@sun.com> <18116.28392.505249.903322@gargle.gargle.HOWL> <46C46D52.3070007@sun.com> <46C93F92.1010904@sun.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Status: RO Content-Length: 695 > Someone might want to build or develop a 3rd party app that uses > libdaemon. If we don't ship the headers, the only option they have is > find the same version that is shipped with Solaris and extract the > headers for themselves. Worse, if they pick the latest version and they > to use those headers with the old library there is likely to be problems. > > So interface classification should be Volatile. Is there a reason you're using Volatile rather than Uncommitted? The latter would not allow incompatible versions changes in a patch while allowing the library to evolve during the creation of a minor release. Or is libdaemon really so unstable that Volatile makes more sense? dsc From carlsonj@phorcys.east.sun.com Mon Aug 20 16:41:45 2007 Received: from dm-east-01.east.sun.com (dm-east-01.East.Sun.COM [129.148.9.192]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l7KNfike001781 for ; Mon, 20 Aug 2007 16:41:44 -0700 (PDT) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id l7KCk4U9053268 for ; Mon, 20 Aug 2007 08:46:04 -0400 (EDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l7KCk4RV101741; Mon, 20 Aug 2007 08:46:04 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.1+Sun/8.14.1/Submit) id l7KCk3JS101738; Mon, 20 Aug 2007 08:46:04 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18121.36107.765134.495767@gargle.gargle.HOWL> Date: Mon, 20 Aug 2007 08:46:03 -0400 From: James Carlson To: "Padraig O'Briain" Cc: Brian Cameron , Joseph Kowalski , John Fischer , lsarc-ext@sac.sfbay.sun.com, psarc@Sun.COM Subject: Re: LSARC/2006/455 Avahi and libdaemon In-Reply-To: <46C93F92.1010904@sun.com> References: <46C33B67.7000904@sun.com> <46C3B9F4.2000805@sun.com> <46C3F9F1.5070308@sun.com> <46C46BDA.9060508@sun.com> <18116.28392.505249.903322@gargle.gargle.HOWL> <46C46D52.3070007@sun.com> <46C93F92.1010904@sun.com> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 1522 Padraig O'Briain writes: > I have spoken to Laca about this and RE's policy is to always deliver > the include files for a library. I think the wires are getting crossed somewhere, because the fact that it's a library alone does not trigger the need to deliver anything other than the .so.1 file. The actual policy is here: http://www.opensolaris.org/os/community/arc/policies/libraries/ See W3. (It's also somewhere on sac.sfbay ... but that system is dead right now.) The key issue is whether this is intended to be private or not. > Someone might want to build or develop a 3rd party app that uses > libdaemon. If we don't ship the headers, the only option they have is > find the same version that is shipped with Solaris and extract the > headers for themselves. Worse, if they pick the latest version and they > to use those headers with the old library there is likely to be problems. No, that's not the only option. They can also download the source themselves and compile a new version of the library, and use that _instead_. Mixing and matching header files and other bits related to an undocumented library would indeed be a bad idea, but it's certainly not the only option if the library is private. > So interface classification should be Volatile. OK. That works. -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From sacadmin Mon Aug 20 16:41:46 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l7KNfjiq001785 for ; Mon, 20 Aug 2007 16:41:46 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l7KNd0mn016460; Tue, 21 Aug 2007 00:39:07 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JN300M05J15YI00@nwk-avmta-1.sfbay.Sun.COM>; Mon, 20 Aug 2007 16:39:05 -0700 (PDT) Received: from izimbra.SFBay.Sun.COM ([129.146.226.141]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JN300CKWJ145X60@nwk-avmta-1.sfbay.Sun.COM>; Mon, 20 Aug 2007 16:39:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by izimbra.SFBay.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id l7KNd3kf314034; Mon, 20 Aug 2007 16:39:04 -0700 (PDT) Date: Mon, 20 Aug 2007 16:39:03 -0700 (PDT) From: David.Comay@sun.com Subject: Re: LSARC/2006/455 Avahi and libdaemon In-reply-to: <46C93F92.1010904@sun.com> Sender: comay@izimbra.sfbay.sun.com To: "Padraig O'Briain" Cc: James Carlson , John Fischer , lsarc-ext@sac.sfbay.sun.com, psarc@sun.com, Joseph Kowalski , Brian Cameron Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <46C33B67.7000904@sun.com> <46C3B9F4.2000805@sun.com> <46C3F9F1.5070308@sun.com> <46C46BDA.9060508@sun.com> <18116.28392.505249.903322@gargle.gargle.HOWL> <46C46D52.3070007@sun.com> <46C93F92.1010904@sun.com> Status: RO Content-Length: 695 > Someone might want to build or develop a 3rd party app that uses > libdaemon. If we don't ship the headers, the only option they have is > find the same version that is shipped with Solaris and extract the > headers for themselves. Worse, if they pick the latest version and they > to use those headers with the old library there is likely to be problems. > > So interface classification should be Volatile. Is there a reason you're using Volatile rather than Uncommitted? The latter would not allow incompatible versions changes in a patch while allowing the library to evolve during the creation of a minor release. Or is libdaemon really so unstable that Volatile makes more sense? dsc From sacadmin Mon Aug 20 17:03:21 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l7L03LM6003586 for ; Mon, 20 Aug 2007 17:03:21 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l7K7aUn3003524 for <@sunmail2sca.sfbay.sun.com:psarc@sun.com>; Mon, 20 Aug 2007 00:36:30 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JN200A0BAGU1I00@nwk-avmta-1.sfbay.Sun.COM> for psarc@sun.com (ORCPT psarc@sun.com); Mon, 20 Aug 2007 00:36:30 -0700 (PDT) Received: from gmp-ea-fw-1.sun.com ([129.156.42.5]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JN2007WNAGMP710@nwk-avmta-1.sfbay.Sun.COM> for psarc@sun.com (ORCPT psarc@sun.com); Mon, 20 Aug 2007 00:36:23 -0700 (PDT) Received: from d1-emea-10.sun.com (d1-emea-10.sun.com [192.18.2.120]) by gmp-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l7K7aL67007684 for ; Mon, 20 Aug 2007 07:36:21 +0000 (GMT) Received: from conversion-daemon.d1-emea-10.sun.com by d1-emea-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JN200601AE9HW00@d1-emea-10.sun.com> (original mail from Padraig.Obriain@Sun.COM) for psarc@sun.com (ORCPT psarc@sun.com); Mon, 20 Aug 2007 08:36:21 +0100 (BST) Received: from [129.156.234.22] by d1-emea-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JN2006RNAGKSDC0@d1-emea-10.sun.com>; Mon, 20 Aug 2007 08:36:21 +0100 (BST) Date: Mon, 20 Aug 2007 08:15:30 +0100 From: "Padraig O'Briain" Subject: Re: LSARC/2006/455 Avahi and libdaemon In-reply-to: <46C46D52.3070007@sun.com> Sender: Padraig.Obriain@sun.com To: James Carlson Cc: Brian Cameron , Joseph Kowalski , John Fischer , lsarc-ext@sac.sfbay.sun.com, psarc@sun.com Message-id: <46C93F92.1010904@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <46C33B67.7000904@sun.com> <46C3B9F4.2000805@sun.com> <46C3F9F1.5070308@sun.com> <46C46BDA.9060508@sun.com> <18116.28392.505249.903322@gargle.gargle.HOWL> <46C46D52.3070007@sun.com> User-Agent: Thunderbird 2.0b2 (X11/20070129) Status: RO Content-Length: 1446 I have spoken to Laca about this and RE's policy is to always deliver the include files for a library. Someone might want to build or develop a 3rd party app that uses libdaemon. If we don't ship the headers, the only option they have is find the same version that is shipped with Solaris and extract the headers for themselves. Worse, if they pick the latest version and they to use those headers with the old library there is likely to be problems. So interface classification should be Volatile. Padraig Padraig O'Briain wrote: > It is my intention that libdaemon.so should be Private. > > The library name is actually libdaemon.so.0.3.0. > This was an error on my part. > > Padraig > > James Carlson wrote: >> Brian Cameron writes: >> >>> My understanding of Sun manpage policy is that all libraries >>> should have manpages, if only to describe that they are Uncommitted >>> in the ATTRIBUTES section and not to be used. >>> >> >> No, if it's intended as "Private," as this one seems to be, then *by >> definition* it must not have man pages. >> >> In that case, it should be shipped as libdaemon.so.1 (not >> libdaemon.so, as the case materials seem to have), and it should omit >> any compilation symlink and associated header files. >> >> If it's meant to be used by multiple projects, and not just this one, >> then it may well need a much closer look and higher commitment, which >> would require a man page. >> >> > From Padraig.Obriain@Sun.COM Tue Aug 21 09:09:58 2007 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca [129.145.155.42]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l7LG9wZV025583 for ; Tue, 21 Aug 2007 09:09:58 -0700 (PDT) Received: from gmp-ea-fw-1.sun.com (gmpes-gis-mail-2.UK.Sun.COM [129.156.42.6]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id l7LG7PKS029374 for ; Tue, 21 Aug 2007 09:07:26 -0700 (PDT) Received: from d1-emea-10.sun.com ([192.18.2.120]) by gmp-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l7LG7KCQ021568 for ; Tue, 21 Aug 2007 16:07:20 GMT Received: from conversion-daemon.d1-emea-10.sun.com by d1-emea-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JN400501SRFMH00@d1-emea-10.sun.com> (original mail from Padraig.Obriain@Sun.COM) for lsarc-ext@sac.sfbay.sun.com; Tue, 21 Aug 2007 17:07:19 +0100 (BST) Received: from [129.156.234.22] by d1-emea-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JN4006WOSS2SQE3@d1-emea-10.sun.com>; Tue, 21 Aug 2007 17:07:15 +0100 (BST) Date: Tue, 21 Aug 2007 16:46:21 +0100 From: "Padraig O'Briain" Subject: Re: LSARC/2006/455 Avahi and libdaemon In-reply-to: Sender: Padraig.Obriain@Sun.COM To: David.Comay@Sun.COM Cc: James Carlson , John Fischer , lsarc-ext@sac.sfbay.sun.com, psarc@Sun.COM, Joseph Kowalski , Brian Cameron Message-id: <46CB08CD.40100@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <46C33B67.7000904@sun.com> <46C3B9F4.2000805@sun.com> <46C3F9F1.5070308@sun.com> <46C46BDA.9060508@sun.com> <18116.28392.505249.903322@gargle.gargle.HOWL> <46C46D52.3070007@sun.com> <46C93F92.1010904@sun.com> User-Agent: Thunderbird 2.0b2 (X11/20070129) Status: RO Content-Length: 983 I said Volatile as that is what our RE recommended to me. Having read the Interface Taxonomy it looks to me that Volatile is the normal classification for free or open source software (FOSS) which is what this is. Padraig Padraig David.Comay@Sun.COM wrote: >> Someone might want to build or develop a 3rd party app that uses >> libdaemon. If we don't ship the headers, the only option they have is >> find the same version that is shipped with Solaris and extract the >> headers for themselves. Worse, if they pick the latest version and they >> to use those headers with the old library there is likely to be >> problems. >> >> So interface classification should be Volatile. > > Is there a reason you're using Volatile rather than Uncommitted? The > latter would not allow incompatible versions changes in a patch while > allowing the library to evolve during the creation of a minor release. > > Or is libdaemon really so unstable that Volatile makes more sense? > > dsc From sacadmin Tue Aug 21 09:10:00 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l7LG9x70025587 for ; Tue, 21 Aug 2007 09:09:59 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l7LG7N0A022372 for <@sunmail2sca.sfbay.sun.com:psarc@sun.com>; Tue, 21 Aug 2007 17:07:26 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JN400B03SSAYN00@brm-avmta-1.central.sun.com> for psarc@sun.com (ORCPT psarc@sun.com); Tue, 21 Aug 2007 10:07:22 -0600 (MDT) Received: from gmp-ea-fw-1.sun.com ([129.156.42.5]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JN4003S3SS86D90@brm-avmta-1.central.sun.com> for psarc@sun.com (ORCPT psarc@sun.com); Tue, 21 Aug 2007 10:07:21 -0600 (MDT) Received: from d1-emea-10.sun.com (d1-emea-10.sun.com [192.18.2.120]) by gmp-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l7LG7Kis001331 for ; Tue, 21 Aug 2007 16:07:20 +0000 (GMT) Received: from conversion-daemon.d1-emea-10.sun.com by d1-emea-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JN400501SRFMH00@d1-emea-10.sun.com> (original mail from Padraig.Obriain@Sun.COM) for psarc@sun.com (ORCPT psarc@sun.com); Tue, 21 Aug 2007 17:07:20 +0100 (BST) Received: from [129.156.234.22] by d1-emea-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JN4006WOSS2SQE3@d1-emea-10.sun.com>; Tue, 21 Aug 2007 17:07:15 +0100 (BST) Date: Tue, 21 Aug 2007 16:46:21 +0100 From: "Padraig O'Briain" Subject: Re: LSARC/2006/455 Avahi and libdaemon In-reply-to: Sender: Padraig.Obriain@sun.com To: David.Comay@sun.com Cc: James Carlson , John Fischer , lsarc-ext@sac.sfbay.sun.com, psarc@sun.com, Joseph Kowalski , Brian Cameron Message-id: <46CB08CD.40100@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <46C33B67.7000904@sun.com> <46C3B9F4.2000805@sun.com> <46C3F9F1.5070308@sun.com> <46C46BDA.9060508@sun.com> <18116.28392.505249.903322@gargle.gargle.HOWL> <46C46D52.3070007@sun.com> <46C93F92.1010904@sun.com> User-Agent: Thunderbird 2.0b2 (X11/20070129) Status: RO Content-Length: 983 I said Volatile as that is what our RE recommended to me. Having read the Interface Taxonomy it looks to me that Volatile is the normal classification for free or open source software (FOSS) which is what this is. Padraig Padraig David.Comay@Sun.COM wrote: >> Someone might want to build or develop a 3rd party app that uses >> libdaemon. If we don't ship the headers, the only option they have is >> find the same version that is shipped with Solaris and extract the >> headers for themselves. Worse, if they pick the latest version and they >> to use those headers with the old library there is likely to be >> problems. >> >> So interface classification should be Volatile. > > Is there a reason you're using Volatile rather than Uncommitted? The > latter would not allow incompatible versions changes in a patch while > allowing the library to evolve during the creation of a minor release. > > Or is libdaemon really so unstable that Volatile makes more sense? > > dsc From carlsonj@phorcys.east.sun.com Tue Aug 21 09:27:00 2007 Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l7LGQxM6026119 for ; Tue, 21 Aug 2007 09:27:00 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l7LGOQpB107344; Tue, 21 Aug 2007 12:24:27 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.1+Sun/8.14.1/Submit) id l7LGOPEe107337; Tue, 21 Aug 2007 12:24:25 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18123.4531.931233.39137@gargle.gargle.HOWL> Date: Tue, 21 Aug 2007 12:24:19 -0400 From: James Carlson To: "Padraig O'Briain" Cc: David.Comay@Sun.COM, John Fischer , lsarc-ext@sac.sfbay.sun.com, Joseph Kowalski , psarc@Sun.COM, Brian Cameron Subject: Re: LSARC/2006/455 Avahi and libdaemon In-Reply-To: <46CB08CD.40100@sun.com> References: <46C33B67.7000904@sun.com> <46C3B9F4.2000805@sun.com> <46C3F9F1.5070308@sun.com> <46C46BDA.9060508@sun.com> <18116.28392.505249.903322@gargle.gargle.HOWL> <46C46D52.3070007@sun.com> <46C93F92.1010904@sun.com> <46CB08CD.40100@sun.com> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 3247 Padraig O'Briain writes: > I said Volatile as that is what our RE recommended to me. > > Having read the Interface Taxonomy it looks to me that Volatile is the > normal classification for free or open source software (FOSS) which is > what this is. Not really wanting to belabor this, but ... There is *NO* direct translation from origin of software into stability level. None. Please delete the notion that FOSS == Volatile, because it's simply not true and it leads to bad decisions. Instead, the stability level is the stability that we are offering the users of that component. We're promising that it won't change in incompatible ways or without notice unless a certain kind of release is made. There are many ways to evaluate and deal with this, and thus the lack of any tie to "is/is not FOSS." For instance, you may determine: 1. You want to upgrade as often as possible without even really thinking about it much; just download source, compile, and go. 2. The upstream source has a poor history of offering compatibility and tends to change things often and break users. 3. You don't really care if users of your component get broken, because getting "newer" bits is more valuable, and perhaps nobody really depends on it anyway. In that case, "Volatile" makes sense. It allows you to introduce incompatibilities even in patches when necessary. Or you may determine: 1. You want to upgrade often. 2. The upstream source has a decent history of offering compatibility or at least properly marking source changes that are incompatible ("flag days"). 3. You don't want to break users if you can avoid it, at least within a Minor release of Solaris. 4. If the upstream does break something anyway, you'll do something to fix it, meaning one or more of: a. Refuse to take that source change; stick with the old version until the next Minor release. b. Contribute fixes upstream to restore compatibility. c. Offer multiple concurrent versions (where feasible). d. If you can't get the changes upstream and must upgrade the bits, then fork the source, and apply local patches to restore compatibility. In that case, "Uncommitted" is probably better. It gives a greater promise to users, and thus allows them more secure use of the software and a better chance of building on it. Similarly, "Committed" can be used for FOSS. It just means that we're promising to break things in the bits that _WE_ deliver only when there's a Major release. Many FOSS projects are well known to be stable enough to promise exactly this level of support. In many ways, "Volatile" is just the worst possible choice for any component. It means that nobody can build on it, because they're building on quicksand. Of course, you can always upgrade the stability later, but few ever bother revisiting the choice, so it's worth putting at least a little thought into it. Simply equating FOSS to Volatile, though, doesn't that. -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From sacadmin Tue Aug 21 09:27:10 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l7LGR9Lw026134 for ; Tue, 21 Aug 2007 09:27:09 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l7LGOLx5003354; Tue, 21 Aug 2007 17:24:32 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JN400D2NTKTDI00@nwk-avmta-2.sfbay.sun.com>; Tue, 21 Aug 2007 09:24:29 -0700 (PDT) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JN400BUETKS9W60@nwk-avmta-2.sfbay.sun.com>; Tue, 21 Aug 2007 09:24:29 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l7LGOQpB107344; Tue, 21 Aug 2007 12:24:27 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.1+Sun/8.14.1/Submit) id l7LGOPEe107337; Tue, 21 Aug 2007 12:24:25 -0400 (EDT) Date: Tue, 21 Aug 2007 12:24:19 -0400 From: James Carlson Subject: Re: LSARC/2006/455 Avahi and libdaemon In-reply-to: <46CB08CD.40100@sun.com> To: "Padraig O'Briain" Cc: David.Comay@sun.com, John Fischer , lsarc-ext@sac.sfbay.sun.com, Joseph Kowalski , psarc@sun.com, Brian Cameron Message-id: <18123.4531.931233.39137@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <46C33B67.7000904@sun.com> <46C3B9F4.2000805@sun.com> <46C3F9F1.5070308@sun.com> <46C46BDA.9060508@sun.com> <18116.28392.505249.903322@gargle.gargle.HOWL> <46C46D52.3070007@sun.com> <46C93F92.1010904@sun.com> <46CB08CD.40100@sun.com> Status: RO Content-Length: 3247 Padraig O'Briain writes: > I said Volatile as that is what our RE recommended to me. > > Having read the Interface Taxonomy it looks to me that Volatile is the > normal classification for free or open source software (FOSS) which is > what this is. Not really wanting to belabor this, but ... There is *NO* direct translation from origin of software into stability level. None. Please delete the notion that FOSS == Volatile, because it's simply not true and it leads to bad decisions. Instead, the stability level is the stability that we are offering the users of that component. We're promising that it won't change in incompatible ways or without notice unless a certain kind of release is made. There are many ways to evaluate and deal with this, and thus the lack of any tie to "is/is not FOSS." For instance, you may determine: 1. You want to upgrade as often as possible without even really thinking about it much; just download source, compile, and go. 2. The upstream source has a poor history of offering compatibility and tends to change things often and break users. 3. You don't really care if users of your component get broken, because getting "newer" bits is more valuable, and perhaps nobody really depends on it anyway. In that case, "Volatile" makes sense. It allows you to introduce incompatibilities even in patches when necessary. Or you may determine: 1. You want to upgrade often. 2. The upstream source has a decent history of offering compatibility or at least properly marking source changes that are incompatible ("flag days"). 3. You don't want to break users if you can avoid it, at least within a Minor release of Solaris. 4. If the upstream does break something anyway, you'll do something to fix it, meaning one or more of: a. Refuse to take that source change; stick with the old version until the next Minor release. b. Contribute fixes upstream to restore compatibility. c. Offer multiple concurrent versions (where feasible). d. If you can't get the changes upstream and must upgrade the bits, then fork the source, and apply local patches to restore compatibility. In that case, "Uncommitted" is probably better. It gives a greater promise to users, and thus allows them more secure use of the software and a better chance of building on it. Similarly, "Committed" can be used for FOSS. It just means that we're promising to break things in the bits that _WE_ deliver only when there's a Major release. Many FOSS projects are well known to be stable enough to promise exactly this level of support. In many ways, "Volatile" is just the worst possible choice for any component. It means that nobody can build on it, because they're building on quicksand. Of course, you can always upgrade the stability later, but few ever bother revisiting the choice, so it's worth putting at least a little thought into it. Simply equating FOSS to Volatile, though, doesn't that. -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From sacadmin Tue Aug 21 09:47:41 2007 Received: from zruty.sfbay.sun.com (zruty [129.146.168.40]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l7LGlfPJ027030 for ; Tue, 21 Aug 2007 09:47:41 -0700 (PDT) Received: from zruty.sfbay.sun.com (localhost [127.0.0.1]) by zruty.sfbay.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l7LGhtKI014665; Tue, 21 Aug 2007 09:43:55 -0700 (PDT) Received: (from dduvall@localhost) by zruty.sfbay.sun.com (8.14.1+Sun/8.14.1/Submit) id l7LGht3U014664; Tue, 21 Aug 2007 09:43:55 -0700 (PDT) Date: Tue, 21 Aug 2007 09:43:55 -0700 From: Danek Duvall To: John Fischer Cc: lsarc@sac.sfbay.sun.com, "Padraig O'Briain" , psarc-ext@sun.com Subject: Re: LSARC/2006/455 Avahi and libdaemon Message-ID: <20070821164355.GG2256@zruty.sfbay.sun.com> References: <46C33B67.7000904@sun.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46C33B67.7000904@sun.com> User-Agent: Mutt/1.5.16 (2007-06-27) Status: RO Content-Length: 902 > This project delivers the avahi client API. Instead of delivering > the avahi daemon, which on linux and freebsd implements a mDNS > stack, we will change the avahi daemon to make calls to the > Bonjour API so that it will use the Bonjour server. This is, IMO, poorly worded and confusing -- "we're not delivering the daemon, but instead are delivering the daemon". Erm. You're delivering the daemon, heavily modified, ripping out its guts and replacing them with a new backend. > avahi-daemon: The avahi daemon makes use of libavahi-core to > provide service registration and discovery to clients using the > DBUS interface which is an IPC wrapper around the functions > provided by avahi-core. We rename this to avahi-daemon-bridge-dsd > so that it is clear that we are not delivering the standard avahi > daemon. From the architectural diagram, is the "DBUS protocol" the only piece of Status: RO the daemon that's getting delivered? Is this a public interface? If not, then why have a long-running daemon at all? Why not just have the client library make the requests via -core (and back to bonjour)? (And if for some reason the daemon is necessary, why isn't it properly integrated with SMF?) > /etc/avahi/hosts Volatile address host mappings > /etc/avahi/services/ssh.service Volatile Static service It'd really be nice to point us at the documentation for this. I see a poorly formatted man page for this in the materials directory, but I shouldn't have to go digging for it. (That's why interface tables have a "defined in document" column.) Why are you choosing to deliver this one service? Why not others? You say it's "static"; what does that mean? Are other services dymanically generated? If so, which? And why not this one? Danek From danek.duvall@sun.com Tue Aug 21 09:47:44 2007 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l7LGlh0B027045 for ; Tue, 21 Aug 2007 09:47:43 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l7LGijW3057779 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Tue, 21 Aug 2007 10:44:52 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JN400E0FUJA4R00@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 21 Aug 2007 09:45:10 -0700 (PDT) Received: from sfbaymail1sca.SFBay.Sun.COM ([129.145.154.35]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JN400B6AUJA9S90@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 21 Aug 2007 09:45:10 -0700 (PDT) Received: from zruty.sfbay.sun.com (zruty.SFBay.Sun.COM [129.146.168.40]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l7LGj9NQ026129; Tue, 21 Aug 2007 09:45:09 -0700 (PDT) Received: from zruty.sfbay.sun.com (localhost [127.0.0.1]) by zruty.sfbay.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l7LGhtKI014665; Tue, 21 Aug 2007 09:43:55 -0700 (PDT) Received: (from dduvall@localhost) by zruty.sfbay.sun.com (8.14.1+Sun/8.14.1/Submit) id l7LGht3U014664; Tue, 21 Aug 2007 09:43:55 -0700 (PDT) Date: Tue, 21 Aug 2007 09:43:55 -0700 From: Danek Duvall Subject: Re: LSARC/2006/455 Avahi and libdaemon In-reply-to: <46C33B67.7000904@sun.com> To: John Fischer Cc: lsarc@sac.sfbay.sun.com, "Padraig O'Briain" , psarc-ext@sun.com Message-id: <20070821164355.GG2256@zruty.sfbay.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <46C33B67.7000904@sun.com> User-Agent: Mutt/1.5.16 (2007-06-27) Status: RO Content-Length: 902 > This project delivers the avahi client API. Instead of delivering > the avahi daemon, which on linux and freebsd implements a mDNS > stack, we will change the avahi daemon to make calls to the > Bonjour API so that it will use the Bonjour server. This is, IMO, poorly worded and confusing -- "we're not delivering the daemon, but instead are delivering the daemon". Erm. You're delivering the daemon, heavily modified, ripping out its guts and replacing them with a new backend. > avahi-daemon: The avahi daemon makes use of libavahi-core to > provide service registration and discovery to clients using the > DBUS interface which is an IPC wrapper around the functions > provided by avahi-core. We rename this to avahi-daemon-bridge-dsd > so that it is clear that we are not delivering the standard avahi > daemon. From the architectural diagram, is the "DBUS protocol" the only piece of Status: RO the daemon that's getting delivered? Is this a public interface? If not, then why have a long-running daemon at all? Why not just have the client library make the requests via -core (and back to bonjour)? (And if for some reason the daemon is necessary, why isn't it properly integrated with SMF?) > /etc/avahi/hosts Volatile address host mappings > /etc/avahi/services/ssh.service Volatile Static service It'd really be nice to point us at the documentation for this. I see a poorly formatted man page for this in the materials directory, but I shouldn't have to go digging for it. (That's why interface tables have a "defined in document" column.) Why are you choosing to deliver this one service? Why not others? You say it's "static"; what does that mean? Are other services dymanically generated? If so, which? And why not this one? Danek From Padraig.Obriain@sun.com Wed Aug 22 02:47:14 2007 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l7M9lDr5029852 for ; Wed, 22 Aug 2007 02:47:14 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l7M9iL7R040894 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Wed, 22 Aug 2007 03:44:21 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JN600M035QGRO00@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 22 Aug 2007 02:44:40 -0700 (PDT) Received: from gmp-ea-fw-1.sun.com ([129.156.42.5]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JN600KOY5QE5W50@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 22 Aug 2007 02:44:40 -0700 (PDT) Received: from d1-emea-09.sun.com (d1-emea-09.sun.com [192.18.2.119]) by gmp-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l7M9icSZ010998 for ; Wed, 22 Aug 2007 09:44:38 +0000 (GMT) Received: from conversion-daemon.d1-emea-09.sun.com by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JN600C015KTA800@d1-emea-09.sun.com> (original mail from Padraig.Obriain@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 22 Aug 2007 10:44:38 +0100 (BST) Received: from [129.156.234.22] by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JN600LRN5QD5BW5@d1-emea-09.sun.com>; Wed, 22 Aug 2007 10:44:37 +0100 (BST) Date: Wed, 22 Aug 2007 10:23:41 +0100 From: "Padraig O'Briain" Subject: Re: LSARC/2006/455 Avahi and libdaemon In-reply-to: <20070821164355.GG2256@zruty.sfbay.sun.com> Sender: Padraig.Obriain@sun.com To: Danek Duvall Cc: John Fischer , lsarc@sac.sfbay.sun.com, psarc-ext@sun.com Message-id: <46CC009D.9070609@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <46C33B67.7000904@sun.com> <20070821164355.GG2256@zruty.sfbay.sun.com> User-Agent: Thunderbird 2.0b2 (X11/20070129) Status: RO Content-Length: 2642 Danek Duvall wrote: >> This project delivers the avahi client API. Instead of delivering >> the avahi daemon, which on linux and freebsd implements a mDNS >> stack, we will change the avahi daemon to make calls to the >> Bonjour API so that it will use the Bonjour server. >> > > This is, IMO, poorly worded and confusing -- "we're not delivering the > daemon, but instead are delivering the daemon". Erm. You're delivering > the daemon, heavily modified, ripping out its guts and replacing them with > a new backend. > > >> avahi-daemon: The avahi daemon makes use of libavahi-core to >> provide service registration and discovery to clients using the >> DBUS interface which is an IPC wrapper around the functions >> provided by avahi-core. We rename this to avahi-daemon-bridge-dsd >> so that it is clear that we are not delivering the standard avahi >> daemon. >> > > The architectural diagram is at http://avahi.org/download/overview.png. I saw no reason to remove the static services support so that should work on Solaris in the same way as other platforms. The static services which are provided are those in the standard avahi. The reason for using the daemon is so that applications which use the DBUS calls rather than the avahi client calls can work on Solaris. I do not know of any such applications currently but there seemed no point in making trouble for ourselves in the future. The daemon is integrated with SMF in that an SMF service svc:/system/avahi-bridge-dsd:default is provided. > From the architectural diagram, is the "DBUS protocol" the only piece of > the daemon that's getting delivered? Is this a public interface? If not, > then why have a long-running daemon at all? Why not just have the client > library make the requests via -core (and back to bonjour)? (And if for > some reason the daemon is necessary, why isn't it properly integrated with > SMF?) > > >> /etc/avahi/hosts Volatile address host mappings >> /etc/avahi/services/ssh.service Volatile Static service >> > > It'd really be nice to point us at the documentation for this. I see a > poorly formatted man page for this in the materials directory, but I > shouldn't have to go digging for it. (That's why interface tables have a > "defined in document" column.) > > Why are you choosing to deliver this one service? Why not others? You say > it's "static"; what does that mean? Are other services dymanically > generated? If so, which? And why not this one? > > Danek > From sacadmin Wed Aug 22 02:47:18 2007 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca [129.145.155.42]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l7M9lIBf029869 for ; Wed, 22 Aug 2007 02:47:18 -0700 (PDT) Received: from gmp-ea-fw-1.sun.com (gmpes-gis-mail-2.UK.Sun.COM [129.156.42.6]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id l7M9ii2X017969 for ; Wed, 22 Aug 2007 02:44:44 -0700 (PDT) Received: from d1-emea-09.sun.com ([192.18.2.119]) by gmp-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l7M9icK0001315 for ; Wed, 22 Aug 2007 09:44:38 GMT Received: from conversion-daemon.d1-emea-09.sun.com by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JN600C015KTA800@d1-emea-09.sun.com> (original mail from Padraig.Obriain@Sun.COM) for lsarc@sac.sfbay.sun.com; Wed, 22 Aug 2007 10:44:38 +0100 (BST) Received: from [129.156.234.22] by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JN600LRN5QD5BW5@d1-emea-09.sun.com>; Wed, 22 Aug 2007 10:44:37 +0100 (BST) Date: Wed, 22 Aug 2007 10:23:41 +0100 From: "Padraig O'Briain" Subject: Re: LSARC/2006/455 Avahi and libdaemon In-reply-to: <20070821164355.GG2256@zruty.sfbay.sun.com> Sender: Padraig.Obriain@Sun.COM To: Danek Duvall Cc: John Fischer , lsarc@sac.sfbay.sun.com, psarc-ext@Sun.COM Message-id: <46CC009D.9070609@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <46C33B67.7000904@sun.com> <20070821164355.GG2256@zruty.sfbay.sun.com> User-Agent: Thunderbird 2.0b2 (X11/20070129) Status: RO Content-Length: 2642 Danek Duvall wrote: >> This project delivers the avahi client API. Instead of delivering >> the avahi daemon, which on linux and freebsd implements a mDNS >> stack, we will change the avahi daemon to make calls to the >> Bonjour API so that it will use the Bonjour server. >> > > This is, IMO, poorly worded and confusing -- "we're not delivering the > daemon, but instead are delivering the daemon". Erm. You're delivering > the daemon, heavily modified, ripping out its guts and replacing them with > a new backend. > > >> avahi-daemon: The avahi daemon makes use of libavahi-core to >> provide service registration and discovery to clients using the >> DBUS interface which is an IPC wrapper around the functions >> provided by avahi-core. We rename this to avahi-daemon-bridge-dsd >> so that it is clear that we are not delivering the standard avahi >> daemon. >> > > The architectural diagram is at http://avahi.org/download/overview.png. I saw no reason to remove the static services support so that should work on Solaris in the same way as other platforms. The static services which are provided are those in the standard avahi. The reason for using the daemon is so that applications which use the DBUS calls rather than the avahi client calls can work on Solaris. I do not know of any such applications currently but there seemed no point in making trouble for ourselves in the future. The daemon is integrated with SMF in that an SMF service svc:/system/avahi-bridge-dsd:default is provided. > From the architectural diagram, is the "DBUS protocol" the only piece of > the daemon that's getting delivered? Is this a public interface? If not, > then why have a long-running daemon at all? Why not just have the client > library make the requests via -core (and back to bonjour)? (And if for > some reason the daemon is necessary, why isn't it properly integrated with > SMF?) > > >> /etc/avahi/hosts Volatile address host mappings >> /etc/avahi/services/ssh.service Volatile Static service >> > > It'd really be nice to point us at the documentation for this. I see a > poorly formatted man page for this in the materials directory, but I > shouldn't have to go digging for it. (That's why interface tables have a > "defined in document" column.) > > Why are you choosing to deliver this one service? Why not others? You say > it's "static"; what does that mean? Are other services dymanically > generated? If so, which? And why not this one? > > Danek > From sacadmin Wed Aug 22 16:43:20 2007 Received: from engmail3mpk.sfbay.Sun.COM (engmail3mpk [129.146.11.26]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l7MNhKTp000286 for ; Wed, 22 Aug 2007 16:43:20 -0700 (PDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l7MNelCc007317; Wed, 22 Aug 2007 16:40:47 -0700 (PDT) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id l7MNfU1H025967; Wed, 22 Aug 2007 16:41:30 -0700 (PDT) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id l7MNfUBO025966; Wed, 22 Aug 2007 16:41:30 -0700 (PDT) Date: Wed, 22 Aug 2007 16:41:30 -0700 (PDT) From: Gary Winiger Message-Id: <200708222341.l7MNfUBO025966@marduk.eng.sun.com> To: Danek.Duvall@Sun.COM, Padraig.Obriain@Sun.COM Cc: John.Fischer@Sun.COM, lsarc@sac.sfbay.sun.com, psarc-ext@Sun.COM Subject: Re: LSARC/2006/455 Avahi and libdaemon Status: RO Content-Length: 629 > The daemon is integrated with SMF in that an SMF service > svc:/system/avahi-bridge-dsd:default is provided. So, I was originally confused about the /etc/ turd files, and now that I see there is an SMF service, I'm more confused. How does this project meet the SMF policy: http://opensolaris.org/os/community/arc/policies/SMF-policy/;jsessionid=FBFDB7649584122060FB3D8F93AEF778 Which includes the use of properties, authorizations and right profiles. Gary.. > >> /etc/avahi/hosts Volatile address host mappings > >> /etc/avahi/services/ssh.service Volatile Static service From gww@eng.sun.com Wed Aug 22 16:43:24 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l7MNhNDk000304 for ; Wed, 22 Aug 2007 16:43:24 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l7MNeoOm025803 for <@sunmail2sca.sfbay.sun.com:psarc-ext@Sun.COM>; Thu, 23 Aug 2007 07:40:51 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JN7008098G16W00@brm-avmta-1.central.sun.com> for psarc-ext@Sun.COM (ORCPT psarc-ext@Sun.COM); Wed, 22 Aug 2007 17:40:49 -0600 (MDT) Received: from engmail3mpk.sfbay.Sun.COM ([129.146.11.26]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JN70017N8G0HTE0@brm-avmta-1.central.sun.com> for psarc-ext@Sun.COM (ORCPT psarc-ext@Sun.COM); Wed, 22 Aug 2007 17:40:48 -0600 (MDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l7MNelCc007317; Wed, 22 Aug 2007 16:40:47 -0700 (PDT) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id l7MNfU1H025967; Wed, 22 Aug 2007 16:41:30 -0700 (PDT) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id l7MNfUBO025966; Wed, 22 Aug 2007 16:41:30 -0700 (PDT) Date: Wed, 22 Aug 2007 16:41:30 -0700 (PDT) From: Gary Winiger Subject: Re: LSARC/2006/455 Avahi and libdaemon To: Danek.Duvall@sun.com, Padraig.Obriain@sun.com Cc: John.Fischer@sun.com, lsarc@sac.sfbay.sun.com, psarc-ext@sun.com Message-id: <200708222341.l7MNfUBO025966@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 629 > The daemon is integrated with SMF in that an SMF service > svc:/system/avahi-bridge-dsd:default is provided. So, I was originally confused about the /etc/ turd files, and now that I see there is an SMF service, I'm more confused. How does this project meet the SMF policy: http://opensolaris.org/os/community/arc/policies/SMF-policy/;jsessionid=FBFDB7649584122060FB3D8F93AEF778 Which includes the use of properties, authorizations and right profiles. Gary.. > >> /etc/avahi/hosts Volatile address host mappings > >> /etc/avahi/services/ssh.service Volatile Static service From jek3@sun.com Wed Aug 22 23:28:00 2007 Received: from jurassic-x4600.sfbay.sun.com (cretaceous [129.146.17.63]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l7N6S0vW006400 for ; Wed, 22 Aug 2007 23:28:00 -0700 (PDT) Received: from [129.150.12.124] (vpn-129-150-12-124.SFBay.Sun.COM [129.150.12.124]) by jurassic-x4600.sfbay.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l7N6PMwe237532; Wed, 22 Aug 2007 23:25:23 -0700 (PDT) Message-ID: <46CD279B.6040905@sun.com> Date: Wed, 22 Aug 2007 20:22:19 -1000 From: Joseph Kowalski User-Agent: Thunderbird 1.5.0.5 (X11/20060925) MIME-Version: 1.0 To: David.Comay@sun.com CC: "Padraig O'Briain" , James Carlson , John Fischer , lsarc-ext@sac.sfbay.sun.com, psarc@sun.com, Brian Cameron Subject: Re: LSARC/2006/455 Avahi and libdaemon References: <46C33B67.7000904@sun.com> <46C3B9F4.2000805@sun.com> <46C3F9F1.5070308@sun.com> <46C46BDA.9060508@sun.com> <18116.28392.505249.903322@gargle.gargle.HOWL> <46C46D52.3070007@sun.com> <46C93F92.1010904@sun.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 1085 David.Comay@sun.com wrote: >> Someone might want to build or develop a 3rd party app that uses >> libdaemon. If we don't ship the headers, the only option they have is >> find the same version that is shipped with Solaris and extract the >> headers for themselves. Worse, if they pick the latest version and they >> to use those headers with the old library there is likely to be >> problems. >> >> So interface classification should be Volatile. > > Is there a reason you're using Volatile rather than Uncommitted? The > latter would not allow incompatible versions changes in a patch while > allowing the library to evolve during the creation of a minor release. > > Or is libdaemon really so unstable that Volatile makes more sense? As per the taxonomy examples, Volatile is rather useless as level for libraries. There seems to be two possibilities. I thought the project was headed towards "Project Private". It seems to have morphed into something Public. If it is some type of Public, it needs to be documented. Perhaps I missed something in the mail trail.... - jek3 From sacadmin Wed Aug 22 23:28:31 2007 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l7N6SVT6006414 for ; Wed, 22 Aug 2007 23:28:31 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l7N6PAfK038292; Thu, 23 Aug 2007 00:25:11 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JN700H05R6HGK00@nwk-avmta-2.sfbay.sun.com>; Wed, 22 Aug 2007 23:25:29 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JN700FP0R6G7T20@nwk-avmta-2.sfbay.sun.com>; Wed, 22 Aug 2007 23:25:28 -0700 (PDT) Received: from [129.150.12.124] (vpn-129-150-12-124.SFBay.Sun.COM [129.150.12.124]) by jurassic-x4600.sfbay.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l7N6PMwe237532; Wed, 22 Aug 2007 23:25:23 -0700 (PDT) Date: Wed, 22 Aug 2007 20:22:19 -1000 From: Joseph Kowalski Subject: Re: LSARC/2006/455 Avahi and libdaemon In-reply-to: To: David.Comay@Sun.COM Cc: "Padraig O'Briain" , James Carlson , John Fischer , lsarc-ext@sac.sfbay.sun.com, psarc@Sun.COM, Brian Cameron Message-id: <46CD279B.6040905@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <46C33B67.7000904@sun.com> <46C3B9F4.2000805@sun.com> <46C3F9F1.5070308@sun.com> <46C46BDA.9060508@sun.com> <18116.28392.505249.903322@gargle.gargle.HOWL> <46C46D52.3070007@sun.com> <46C93F92.1010904@sun.com> User-Agent: Thunderbird 1.5.0.5 (X11/20060925) Status: RO Content-Length: 1085 David.Comay@sun.com wrote: >> Someone might want to build or develop a 3rd party app that uses >> libdaemon. If we don't ship the headers, the only option they have is >> find the same version that is shipped with Solaris and extract the >> headers for themselves. Worse, if they pick the latest version and they >> to use those headers with the old library there is likely to be >> problems. >> >> So interface classification should be Volatile. > > Is there a reason you're using Volatile rather than Uncommitted? The > latter would not allow incompatible versions changes in a patch while > allowing the library to evolve during the creation of a minor release. > > Or is libdaemon really so unstable that Volatile makes more sense? As per the taxonomy examples, Volatile is rather useless as level for libraries. There seems to be two possibilities. I thought the project was headed towards "Project Private". It seems to have morphed into something Public. If it is some type of Public, it needs to be documented. Perhaps I missed something in the mail trail.... - jek3 From sacadmin Mon Aug 27 10:29:58 2007 Received: from zruty.sfbay.sun.com (zruty [129.146.168.40]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l7RHTwnD015160 for ; Mon, 27 Aug 2007 10:29:58 -0700 (PDT) Received: from zruty.sfbay.sun.com (localhost [127.0.0.1]) by zruty.sfbay.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l7RHQ4ji004373; Mon, 27 Aug 2007 10:26:04 -0700 (PDT) Received: (from dduvall@localhost) by zruty.sfbay.sun.com (8.14.1+Sun/8.14.1/Submit) id l7RHQ4qL004372; Mon, 27 Aug 2007 10:26:04 -0700 (PDT) Date: Mon, 27 Aug 2007 10:26:04 -0700 From: Danek Duvall To: "Padraig O'Briain" Cc: John Fischer , lsarc@sac.sfbay.sun.com, psarc-ext@Sun.COM Subject: Re: LSARC/2006/455 Avahi and libdaemon Message-ID: <20070827172604.GT1910@zruty.sfbay.sun.com> References: <46C33B67.7000904@sun.com> <20070821164355.GG2256@zruty.sfbay.sun.com> <46CC009D.9070609@sun.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46CC009D.9070609@sun.com> User-Agent: Mutt/1.5.16 (2007-06-27) Status: RO Content-Length: 2513 On Wed, Aug 22, 2007 at 10:23:41AM +0100, Padraig O'Briain wrote: > The architectural diagram is at http://avahi.org/download/overview.png. Yes, I saw that. I just didn't see any reason to ship the daemon, given that its only clients appear to be part of avahi (I think; I may be misreading the diagram). The diagram also doesn't take into account the changes you're making to avahi to use bonjour instead of the mdns stack in avahi (i.e., it's not the architectural diagram for your project, but a different, somewhat related project). Also, all architecturally-relevant materials need to be part of the case materials, and not somewhere out in the wild blue yonder. > I saw no reason to remove the static services support so that should work > on Solaris in the same way as other platforms. The static services which > are provided are those in the standard avahi. > > The reason for using the daemon is so that applications which use the DBUS > calls rather than the avahi client calls can work on Solaris. I do not know > of any such applications currently but there seemed no point in making > trouble for ourselves in the future. > > The daemon is integrated with SMF in that an SMF service > svc:/system/avahi-bridge-dsd:default is provided. Okay. Does the avahi community expect others to use the DBUS interface directly? That is, do they consider it a Public interface? If so, you need to expose that as part of your ARC case, as well as the SMF service. Now, what bothers me here (assuming that they will someday be useful) is that running the DBUS bits isn't optional at the moment. That is, all calls to the avahi client API go through DBUS and the avahi daemon, and then through the bonjour daemon. That's just very silly. Perhaps the Bonjour daemon could be taught to speak DBUS appropriately? >>> /etc/avahi/hosts Volatile address host >>> mappings >>> /etc/avahi/services/ssh.service Volatile Static service >>> >> >> It'd really be nice to point us at the documentation for this. I see a >> poorly formatted man page for this in the materials directory, but I >> shouldn't have to go digging for it. (That's why interface tables have a >> "defined in document" column.) >> >> Why are you choosing to deliver this one service? Why not others? You >> say >> it's "static"; what does that mean? Are other services dymanically >> generated? If so, which? And why not this one? You didn't answer these questions. Danek From danek.duvall@sun.com Mon Aug 27 10:30:05 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l7RHU46V015177 for ; Mon, 27 Aug 2007 10:30:04 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l7RHRIGf019950 for <@sunmail2sca.sfbay.sun.com:psarc-ext@Sun.COM>; Tue, 28 Aug 2007 01:27:26 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JNG00F0N0HN2H00@brm-avmta-1.central.sun.com> for psarc-ext@Sun.COM (ORCPT psarc-ext@Sun.COM); Mon, 27 Aug 2007 11:27:23 -0600 (MDT) Received: from sfbaymail2sca.sfbay.sun.com ([129.145.155.42]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JNG00EEE0HML700@brm-avmta-1.central.sun.com> for psarc-ext@Sun.COM (ORCPT psarc-ext@Sun.COM); Mon, 27 Aug 2007 11:27:22 -0600 (MDT) Received: from zruty.sfbay.sun.com (zruty.SFBay.Sun.COM [129.146.168.40]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id l7RHRKs1002484; Mon, 27 Aug 2007 10:27:20 -0700 (PDT) Received: from zruty.sfbay.sun.com (localhost [127.0.0.1]) by zruty.sfbay.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l7RHQ4ji004373; Mon, 27 Aug 2007 10:26:04 -0700 (PDT) Received: (from dduvall@localhost) by zruty.sfbay.sun.com (8.14.1+Sun/8.14.1/Submit) id l7RHQ4qL004372; Mon, 27 Aug 2007 10:26:04 -0700 (PDT) Date: Mon, 27 Aug 2007 10:26:04 -0700 From: Danek Duvall Subject: Re: LSARC/2006/455 Avahi and libdaemon In-reply-to: <46CC009D.9070609@sun.com> To: "Padraig O'Briain" Cc: John Fischer , lsarc@sac.sfbay.sun.com, psarc-ext@sun.com Message-id: <20070827172604.GT1910@zruty.sfbay.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <46C33B67.7000904@sun.com> <20070821164355.GG2256@zruty.sfbay.sun.com> <46CC009D.9070609@sun.com> User-Agent: Mutt/1.5.16 (2007-06-27) Status: RO Content-Length: 2513 On Wed, Aug 22, 2007 at 10:23:41AM +0100, Padraig O'Briain wrote: > The architectural diagram is at http://avahi.org/download/overview.png. Yes, I saw that. I just didn't see any reason to ship the daemon, given that its only clients appear to be part of avahi (I think; I may be misreading the diagram). The diagram also doesn't take into account the changes you're making to avahi to use bonjour instead of the mdns stack in avahi (i.e., it's not the architectural diagram for your project, but a different, somewhat related project). Also, all architecturally-relevant materials need to be part of the case materials, and not somewhere out in the wild blue yonder. > I saw no reason to remove the static services support so that should work > on Solaris in the same way as other platforms. The static services which > are provided are those in the standard avahi. > > The reason for using the daemon is so that applications which use the DBUS > calls rather than the avahi client calls can work on Solaris. I do not know > of any such applications currently but there seemed no point in making > trouble for ourselves in the future. > > The daemon is integrated with SMF in that an SMF service > svc:/system/avahi-bridge-dsd:default is provided. Okay. Does the avahi community expect others to use the DBUS interface directly? That is, do they consider it a Public interface? If so, you need to expose that as part of your ARC case, as well as the SMF service. Now, what bothers me here (assuming that they will someday be useful) is that running the DBUS bits isn't optional at the moment. That is, all calls to the avahi client API go through DBUS and the avahi daemon, and then through the bonjour daemon. That's just very silly. Perhaps the Bonjour daemon could be taught to speak DBUS appropriately? >>> /etc/avahi/hosts Volatile address host >>> mappings >>> /etc/avahi/services/ssh.service Volatile Static service >>> >> >> It'd really be nice to point us at the documentation for this. I see a >> poorly formatted man page for this in the materials directory, but I >> shouldn't have to go digging for it. (That's why interface tables have a >> "defined in document" column.) >> >> Why are you choosing to deliver this one service? Why not others? You >> say >> it's "static"; what does that mean? Are other services dymanically >> generated? If so, which? And why not this one? You didn't answer these questions. Danek From sacadmin Fri Sep 7 09:30:54 2007 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca [129.145.155.42]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l87GUsYw026358 for ; Fri, 7 Sep 2007 09:30:54 -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 l87GS7nL010025 for ; Fri, 7 Sep 2007 09:28:07 -0700 (PDT) Received: from fe-amer-01.sun.com ([192.18.108.175]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l87GS78Y022115 for ; Fri, 7 Sep 2007 16:28:07 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 <0JO000801B2TZE00@mail-amer.sun.com> (original mail from John.Fischer@Sun.COM) for lsarc@sac.sfbay.sun.com; Fri, 07 Sep 2007 10:28:07 -0600 (MDT) Received: from 129.145.154.101 ([129.145.154.101]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JO0009BQB2T6S86@mail-amer.sun.com>; Fri, 07 Sep 2007 10:28:06 -0600 (MDT) Date: Fri, 07 Sep 2007 09:28:05 -0700 From: John Fischer Subject: Re: LSARC/2006/455 Avahi and libdaemon Sender: John.Fischer@Sun.COM To: lsarc@sac.sfbay.sun.com, psarc-ext@Sun.COM Cc: Padraig.Obriain@Sun.COM Reply-to: John.Fischer@Sun.COM Message-id: <1189182484.64344.21.camel@sr1-umpk-51> MIME-version: 1.0 X-Mailer: Ximian Evolution 1.4.6.301c Content-type: multipart/mixed; boundary="Boundary_(ID_oIEIjMNX0FutfxpBBXRdbw)" Status: RO Content-Length: 15269 --Boundary_(ID_oIEIjMNX0FutfxpBBXRdbw) Content-type: text/plain Content-transfer-encoding: 7BIT All, Padraig has update the proposal (see attached) and provided the SMF manifest. We believe that these address the issues raised. I have also placed these in the case directory along with the overview diagram. Thanks, John --Boundary_(ID_oIEIjMNX0FutfxpBBXRdbw) Content-type: text/xml; charset=ASCII; name=avahi-bridge-dsd.xml Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=avahi-bridge-dsd.xml --Boundary_(ID_oIEIjMNX0FutfxpBBXRdbw) Content-type: text/plain; charset=ASCII; name=proposal.txt Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=proposal.txt 1. Introduction 1.1. Project/Component Working Name: Avahi and libdaemon 1.2. Name of Document Author/Supplier: Padraig O'Briain 1.3. The name of your business unit: JDS Desktop Engineering, Open Source Software, OPG 1.4. Email Aliases: 1.4.1. Responsible Manager: Leo Binchy 1.4.2. Responsible Engineer: Padraig O'Briain 1.4.3. Marketing Manager: Jeff Mc Meekin 1.4.4. Interest List: desktop-cteam@sun.com nwam-bonjour@sun.com bonjour-iteam@sun.com 2. Project Summary 2.1. Project Description: The Multicast DNS (mDNS) and Service Discovery project introduces DNS server-less link-local IP address resolution for ad-hoc networks and discovery of devices and services. See PSARC/2005/562. That project is based on Apple's implementation, a.k.a Bonjour. An alternative implementation is avahi, see www.avahi.org. Some GNOME components provide support for service registration and discovery using avahi. This project delivers the avahi client API. Instead of delivering the avahi daemon, which on linux and freebsd implements a mDNS stack, we will change the avahi daemon to make calls to the Bonjour API so that it will use the Bonjour server. Thus this project depends on PSARC/2005/562. libdaemon is a lightweight C library that eases the writing of UNIX daemons and is used by the avahi daemon. 4. Technical Description: 4.1. Details: Avahi consists of several parts: libavahi-common: a library containing some functions used by avahi clients and the avahi daemon itself. libavahi-core: A library implement service registration and discovery. libavahi-client: A minimal wrapper around the DBUS API to simplify its usage. It hides the DBUS internals completely. libavahi-glib: An adaptor for connecting avahi-client or avahi-core to a GLIB main loop. avahi-daemon: The avahi daemon makes use of libavahi-core to provide service registration and discovery to clients using the DBUS interface which is an IPC wrapper around the functions provided by avahi-core. We rename this to avahi-daemon-bridge-dsd so that it is clear that we are not delivering the standard avahi daemon. ! We have changed avahi-daemon to implement its functionality by ! making calls to Bonjour. We have done this rather than implement ! Bonjour calls in avahi client to maintain as close to a pure Avahi ! environment as possible. If in the future a new client component ! uses the DBUS interface instead of the avahi client API we will be ! able to ship that component. avahi-browse, avahi-discover, avahi-publish, avahi-resolve: Some command line utilities which use libavahi-client. See http://www.avahi.org/wiki/ArchitecturalOverview, which lists some other parts of avahi which we do not deliver. We make significant changes to avahi daemon and libavahi-core. Instead of implementing a mDNS/DNS-SD stack libavahi-core makes calls to the DNS Service Discovery API provided by Bonjour to register and discover services. As the avahi daemon does not provide service registration and discovery itself those portions related to being a mDNS server are omitted. libdaemon is a lightweight C library that eases the writing of UNIX daemons. It consists of the following parts: * A wrapper around fork() which does the correct daemonization procedure of a process * A wrapper around syslog() for simpler and compatible log output to Syslog or STDERR * An API for writing PID files * An API for serializing UNIX signals into a pipe for usage with select() or poll() * An API for running subprocesses with STDOUT and STDERR redirected to syslog. 4.2. Bug/RFE Number(s): N/A. 4.3. In Scope: The project team will integrate and support versions of Avahi continually throughout its life within the Solaris OS. The project team will mark the interfaces of Avahi as appropriate [detailed below] and work with other project teams to provide contracts of use, until such a stage where the technology can be considered as 'Committed' according to the interface taxonomy rules. 4.4. Out of Scope: Sun does not expect to be involved in the development and direction of avahi or libdaemon. Where possible, we will ship 'as is', with the changes to call Bonjour. Any developer changes will be pushed upstream where appropriate. 4.5. Interfaces: Exported Interfaces SUNWlibdaemon Uncommitted Package name for libdaemon Two packages SUNWlibdaemon and SUNWlibdaemon-devel are delivered. /usr/lib/libdaemon.so Volatile libdaemon C library /usr/lib/pkgconfig/libdaemon.pc pkgconfig file for Volatile libdaemon Volatile libdaemon API /usr/include/libdaemon/daemon.h /usr/include/libdaemon/dexec.h /usr/include/libdaemon/dfork.h /usr/include/libdaemon/dlog.h /usr/include/libdaemon/dnoblock.h /usr/include/libdaemon/dpid.h /usr/include/libdaemon/dsignal.h SUNWavahi-bridge-dsd Uncommitted Package name for avahi. Three packages SUNWavahi-bridge-dsd, SUNWavahi-bridge-dsd-devel and SUNWavahi-bridge-dsd-root are delivered. /etc/dbus-1/system.d/avahi-dbus.conf Configuration file for Volatile avahi DBUS messages. ! /var/run/avahi-daemon-bridge-dsd/pid Project Private PID file for avahi. svc:/system/avahi-bridge-dsd:default Volatile SMF service to start avahi-daemon-bridge-dsd. Volatile Avahi APIs. /usr/include/avahi-client/client.h /usr/include/avahi-client/lookup.h /usr/include/avahi-client/publish.h /usr/include/avahi-common/address.h /usr/include/avahi-common/address.h /usr/include/avahi-common/alternative.h /usr/include/avahi-common/cdecl.h /usr/include/avahi-common/defs.h /usr/include/avahi-common/domain.h /usr/include/avahi-common/error.h /usr/include/avahi-common/gccmacro.h /usr/include/avahi-common/llist.h /usr/include/avahi-common/malloc.h /usr/include/avahi-common/rlist.h /usr/include/avahi-common/simple-watch.h /usr/include/avahi-common/strlst.h /usr/include/avahi-common/thread-watch.h /usr/include/avahi-common/timeval.h /usr/include/avahi-common/watch.h /usr/include/avahi-core/core.h /usr/include/avahi-core/log.h /usr/include/avahi-core/lookup.h /usr/include/avahi-core/publish.h /usr/include/avahi-core/rr.h /usr/include/avahi-glib/glib-malloc.h /usr/include/avahi-glib/glib-watch.h /usr/lib/pkgconfig/avahi-client.pc pkgconfig files for /usr/lib/pkgconfig/avahi-core.pc avahi-core, avahi-client /usr/lib/pkgconfig/avahi-glib.pc and avahi-glib bindings. Volatile /usr/bin/avahi-browse Volatile Command line utilities /usr/bin/avahi-discover /usr/bin/bssh /usr/bin/bvnc (this is a link to /usr/bin/bssh) /usr/share/avahi/interfaces/avahi-discover.glade /usr/share/applications/avahi-discover.desktop /usr/bin/avahi-publish /usr/bin/avahi-resolve /usr/bin/avahi-set-host-name /usr/sbin/avahi-daemon-bridge-dsd Volatile Avahi server daemon. Volatile Avahi libraries /usr/lib/libavahi-client.so.3.2.0 /usr/lib/libavahi-common.so.3.4.2 /usr/lib/libavahi-core.so.4.0.4 /usr/lib/libavahi-glib.so.1.0.1 Volatile Avahi python bindings /usr/lib/python2.4/vendor-packages/avahi/ServiceTypeDatabase.py /usr/lib/python2.4/vendor-packages/avahi/SimpleGladeApp.py /usr/lib/python2.4/vendor-packages/avahi/SimpleGladeApp.pyc /usr/lib/python2.4/vendor-packages/avahi/__init__.py /usr/lib/python2.4/vendor-packages/avahi/__init__.pyc Volatile Avahi DBUS Introspection /usr/share/avahi/introspection/AddressResolver.introspect /usr/share/avahi/introspection/DomainBrowser.introspect /usr/share/avahi/introspection/EntryGroup.introspect /usr/share/avahi/introspection/HostNameResolver.introspect /usr/share/avahi/introspection/RecordBrowser.introspect /usr/share/avahi/introspection/Server.introspect /usr/share/avahi/introspection/ServiceBrowser.introspect /usr/share/avahi/introspection/ServiceResolver.introspect /usr/share/avahi/introspection/ServiceTypeBrowser.introspect Volatile Avahi Service Types database /usr/share/avahi/service-types /usr/share/avahi/service-types.DB.Dir /usr/share/avahi/service-types.db.pag /usr/share/avahi/avahi-service.dtd Volatile Man pages /usr/share/man/man1/avahi-browse.1 /usr/share/man/man1/avahi-daemon-bridge-dsd.1 /usr/share/man/man1/avahi-discover.1 /usr/share/man/man1/avahi-publish.1 /usr/share/man/man1/avahi-resolve.1 /usr/share/man/man1/avahi-set-host-name.1 /usr/share/man/man1/bssh /usr/share/man/man1/bvnc (this is a link to /usr/share/man/man1/bssh) ! Imported Interfaces - libxml Committed PSARC 2001/175 Glib Committed LSARC 2006/462 pkg-config Volatile LSARC 2002/747 Python Volatile PSARC 2005/532 DBUS Volatile LSARC 2006/368 libdns-sd (Bonjour) Committed PSARC 2005/562 4.6. Doc Impact: Documentation will be provided as is standard with the Solaris OS - both in terms of developer references, man pages, and command line help. 4.7. Admin/Config Impact: 4.8. HA Impact: None. 4.9. I18N/L10N Impact: None. 4.10. Packaging & Delivery: This project is built, packaged and delivered as part of the current JDS desktop consolidation. 4.11. Security Impact: The process avahi-daemon-bridge-dsd will run as user daemon. No other known security impact. 4.12. Dependencies: LSARC 2006/462 - GNOME 2.16 LSARC 2002/747 - GNOME 2.0 pkg-config PSARC 2001/175 - libxml LSARC 2006/368 - D-BUS Message Bus System 5. Reference Documents: Avahi Community Website http://www.avahi.org Exisitng ARC cases LSARC 2006/462 - GNOME 2.16 PSARC 2005/562 - Multicast DNS and Service Discovery --Boundary_(ID_oIEIjMNX0FutfxpBBXRdbw)-- From John.Fischer@sun.com Fri Sep 7 09:30:57 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l87GUvTr026375 for ; Fri, 7 Sep 2007 09:30:57 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l87GS82e015368 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Fri, 7 Sep 2007 09:28:10 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JO00030LB2XE600@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@Sun.COM); Fri, 07 Sep 2007 10:28:09 -0600 (MDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JO000H2ZB2VA390@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@Sun.COM); Fri, 07 Sep 2007 10:28:07 -0600 (MDT) Received: from fe-amer-01.sun.com ([192.18.108.175]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l87GS7Pc025465 for ; Fri, 07 Sep 2007 16:28:07 +0000 (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 <0JO000801B2TZE00@mail-amer.sun.com> (original mail from John.Fischer@Sun.COM) for psarc-ext@Sun.COM (ORCPT psarc-ext@Sun.COM); Fri, 07 Sep 2007 10:28:07 -0600 (MDT) Received: from 129.145.154.101 ([129.145.154.101]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JO0009BQB2T6S86@mail-amer.sun.com>; Fri, 07 Sep 2007 10:28:06 -0600 (MDT) Date: Fri, 07 Sep 2007 09:28:05 -0700 From: John Fischer Subject: Re: LSARC/2006/455 Avahi and libdaemon Sender: John.Fischer@sun.com To: lsarc@sac.sfbay.sun.com, psarc-ext@sun.com Cc: Padraig.Obriain@sun.com Reply-to: John.Fischer@sun.com Message-id: <1189182484.64344.21.camel@sr1-umpk-51> MIME-version: 1.0 X-Mailer: Ximian Evolution 1.4.6.301c Content-type: multipart/mixed; boundary="Boundary_(ID_AuRsp+BrEzXg+qoz8R0gFw)" X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 15269 --Boundary_(ID_AuRsp+BrEzXg+qoz8R0gFw) Content-type: text/plain Content-transfer-encoding: 7BIT All, Padraig has update the proposal (see attached) and provided the SMF manifest. We believe that these address the issues raised. I have also placed these in the case directory along with the overview diagram. Thanks, John --Boundary_(ID_AuRsp+BrEzXg+qoz8R0gFw) Content-type: text/xml; charset=ASCII; name=avahi-bridge-dsd.xml Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=avahi-bridge-dsd.xml --Boundary_(ID_AuRsp+BrEzXg+qoz8R0gFw) Content-type: text/plain; charset=ASCII; name=proposal.txt Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=proposal.txt 1. Introduction 1.1. Project/Component Working Name: Avahi and libdaemon 1.2. Name of Document Author/Supplier: Padraig O'Briain 1.3. The name of your business unit: JDS Desktop Engineering, Open Source Software, OPG 1.4. Email Aliases: 1.4.1. Responsible Manager: Leo Binchy 1.4.2. Responsible Engineer: Padraig O'Briain 1.4.3. Marketing Manager: Jeff Mc Meekin 1.4.4. Interest List: desktop-cteam@sun.com nwam-bonjour@sun.com bonjour-iteam@sun.com 2. Project Summary 2.1. Project Description: The Multicast DNS (mDNS) and Service Discovery project introduces DNS server-less link-local IP address resolution for ad-hoc networks and discovery of devices and services. See PSARC/2005/562. That project is based on Apple's implementation, a.k.a Bonjour. An alternative implementation is avahi, see www.avahi.org. Some GNOME components provide support for service registration and discovery using avahi. This project delivers the avahi client API. Instead of delivering the avahi daemon, which on linux and freebsd implements a mDNS stack, we will change the avahi daemon to make calls to the Bonjour API so that it will use the Bonjour server. Thus this project depends on PSARC/2005/562. libdaemon is a lightweight C library that eases the writing of UNIX daemons and is used by the avahi daemon. 4. Technical Description: 4.1. Details: Avahi consists of several parts: libavahi-common: a library containing some functions used by avahi clients and the avahi daemon itself. libavahi-core: A library implement service registration and discovery. libavahi-client: A minimal wrapper around the DBUS API to simplify its usage. It hides the DBUS internals completely. libavahi-glib: An adaptor for connecting avahi-client or avahi-core to a GLIB main loop. avahi-daemon: The avahi daemon makes use of libavahi-core to provide service registration and discovery to clients using the DBUS interface which is an IPC wrapper around the functions provided by avahi-core. We rename this to avahi-daemon-bridge-dsd so that it is clear that we are not delivering the standard avahi daemon. ! We have changed avahi-daemon to implement its functionality by ! making calls to Bonjour. We have done this rather than implement ! Bonjour calls in avahi client to maintain as close to a pure Avahi ! environment as possible. If in the future a new client component ! uses the DBUS interface instead of the avahi client API we will be ! able to ship that component. avahi-browse, avahi-discover, avahi-publish, avahi-resolve: Some command line utilities which use libavahi-client. See http://www.avahi.org/wiki/ArchitecturalOverview, which lists some other parts of avahi which we do not deliver. We make significant changes to avahi daemon and libavahi-core. Instead of implementing a mDNS/DNS-SD stack libavahi-core makes calls to the DNS Service Discovery API provided by Bonjour to register and discover services. As the avahi daemon does not provide service registration and discovery itself those portions related to being a mDNS server are omitted. libdaemon is a lightweight C library that eases the writing of UNIX daemons. It consists of the following parts: * A wrapper around fork() which does the correct daemonization procedure of a process * A wrapper around syslog() for simpler and compatible log output to Syslog or STDERR * An API for writing PID files * An API for serializing UNIX signals into a pipe for usage with select() or poll() * An API for running subprocesses with STDOUT and STDERR redirected to syslog. 4.2. Bug/RFE Number(s): N/A. 4.3. In Scope: The project team will integrate and support versions of Avahi continually throughout its life within the Solaris OS. The project team will mark the interfaces of Avahi as appropriate [detailed below] and work with other project teams to provide contracts of use, until such a stage where the technology can be considered as 'Committed' according to the interface taxonomy rules. 4.4. Out of Scope: Sun does not expect to be involved in the development and direction of avahi or libdaemon. Where possible, we will ship 'as is', with the changes to call Bonjour. Any developer changes will be pushed upstream where appropriate. 4.5. Interfaces: Exported Interfaces SUNWlibdaemon Uncommitted Package name for libdaemon Two packages SUNWlibdaemon and SUNWlibdaemon-devel are delivered. /usr/lib/libdaemon.so Volatile libdaemon C library /usr/lib/pkgconfig/libdaemon.pc pkgconfig file for Volatile libdaemon Volatile libdaemon API /usr/include/libdaemon/daemon.h /usr/include/libdaemon/dexec.h /usr/include/libdaemon/dfork.h /usr/include/libdaemon/dlog.h /usr/include/libdaemon/dnoblock.h /usr/include/libdaemon/dpid.h /usr/include/libdaemon/dsignal.h SUNWavahi-bridge-dsd Uncommitted Package name for avahi. Three packages SUNWavahi-bridge-dsd, SUNWavahi-bridge-dsd-devel and SUNWavahi-bridge-dsd-root are delivered. /etc/dbus-1/system.d/avahi-dbus.conf Configuration file for Volatile avahi DBUS messages. ! /var/run/avahi-daemon-bridge-dsd/pid Project Private PID file for avahi. svc:/system/avahi-bridge-dsd:default Volatile SMF service to start avahi-daemon-bridge-dsd. Volatile Avahi APIs. /usr/include/avahi-client/client.h /usr/include/avahi-client/lookup.h /usr/include/avahi-client/publish.h /usr/include/avahi-common/address.h /usr/include/avahi-common/address.h /usr/include/avahi-common/alternative.h /usr/include/avahi-common/cdecl.h /usr/include/avahi-common/defs.h /usr/include/avahi-common/domain.h /usr/include/avahi-common/error.h /usr/include/avahi-common/gccmacro.h /usr/include/avahi-common/llist.h /usr/include/avahi-common/malloc.h /usr/include/avahi-common/rlist.h /usr/include/avahi-common/simple-watch.h /usr/include/avahi-common/strlst.h /usr/include/avahi-common/thread-watch.h /usr/include/avahi-common/timeval.h /usr/include/avahi-common/watch.h /usr/include/avahi-core/core.h /usr/include/avahi-core/log.h /usr/include/avahi-core/lookup.h /usr/include/avahi-core/publish.h /usr/include/avahi-core/rr.h /usr/include/avahi-glib/glib-malloc.h /usr/include/avahi-glib/glib-watch.h /usr/lib/pkgconfig/avahi-client.pc pkgconfig files for /usr/lib/pkgconfig/avahi-core.pc avahi-core, avahi-client /usr/lib/pkgconfig/avahi-glib.pc and avahi-glib bindings. Volatile /usr/bin/avahi-browse Volatile Command line utilities /usr/bin/avahi-discover /usr/bin/bssh /usr/bin/bvnc (this is a link to /usr/bin/bssh) /usr/share/avahi/interfaces/avahi-discover.glade /usr/share/applications/avahi-discover.desktop /usr/bin/avahi-publish /usr/bin/avahi-resolve /usr/bin/avahi-set-host-name /usr/sbin/avahi-daemon-bridge-dsd Volatile Avahi server daemon. Volatile Avahi libraries /usr/lib/libavahi-client.so.3.2.0 /usr/lib/libavahi-common.so.3.4.2 /usr/lib/libavahi-core.so.4.0.4 /usr/lib/libavahi-glib.so.1.0.1 Volatile Avahi python bindings /usr/lib/python2.4/vendor-packages/avahi/ServiceTypeDatabase.py /usr/lib/python2.4/vendor-packages/avahi/SimpleGladeApp.py /usr/lib/python2.4/vendor-packages/avahi/SimpleGladeApp.pyc /usr/lib/python2.4/vendor-packages/avahi/__init__.py /usr/lib/python2.4/vendor-packages/avahi/__init__.pyc Volatile Avahi DBUS Introspection /usr/share/avahi/introspection/AddressResolver.introspect /usr/share/avahi/introspection/DomainBrowser.introspect /usr/share/avahi/introspection/EntryGroup.introspect /usr/share/avahi/introspection/HostNameResolver.introspect /usr/share/avahi/introspection/RecordBrowser.introspect /usr/share/avahi/introspection/Server.introspect /usr/share/avahi/introspection/ServiceBrowser.introspect /usr/share/avahi/introspection/ServiceResolver.introspect /usr/share/avahi/introspection/ServiceTypeBrowser.introspect Volatile Avahi Service Types database /usr/share/avahi/service-types /usr/share/avahi/service-types.DB.Dir /usr/share/avahi/service-types.db.pag /usr/share/avahi/avahi-service.dtd Volatile Man pages /usr/share/man/man1/avahi-browse.1 /usr/share/man/man1/avahi-daemon-bridge-dsd.1 /usr/share/man/man1/avahi-discover.1 /usr/share/man/man1/avahi-publish.1 /usr/share/man/man1/avahi-resolve.1 /usr/share/man/man1/avahi-set-host-name.1 /usr/share/man/man1/bssh /usr/share/man/man1/bvnc (this is a link to /usr/share/man/man1/bssh) ! Imported Interfaces - libxml Committed PSARC 2001/175 Glib Committed LSARC 2006/462 pkg-config Volatile LSARC 2002/747 Python Volatile PSARC 2005/532 DBUS Volatile LSARC 2006/368 libdns-sd (Bonjour) Committed PSARC 2005/562 4.6. Doc Impact: Documentation will be provided as is standard with the Solaris OS - both in terms of developer references, man pages, and command line help. 4.7. Admin/Config Impact: 4.8. HA Impact: None. 4.9. I18N/L10N Impact: None. 4.10. Packaging & Delivery: This project is built, packaged and delivered as part of the current JDS desktop consolidation. 4.11. Security Impact: The process avahi-daemon-bridge-dsd will run as user daemon. No other known security impact. 4.12. Dependencies: LSARC 2006/462 - GNOME 2.16 LSARC 2002/747 - GNOME 2.0 pkg-config PSARC 2001/175 - libxml LSARC 2006/368 - D-BUS Message Bus System 5. Reference Documents: Avahi Community Website http://www.avahi.org Exisitng ARC cases LSARC 2006/462 - GNOME 2.16 PSARC 2005/562 - Multicast DNS and Service Discovery --Boundary_(ID_AuRsp+BrEzXg+qoz8R0gFw)--