WebSVN – nexmon – Blame – Rev 1 – /utilities/glib/docs/reference/gio/overview.xml

1

office

1

<part>

2

<title>GIO Overview</title>

3

4

<chapter>

5

<title>Introduction</title>

6

7

<para>

8

GIO is striving to provide a modern, easy-to-use VFS API that sits

9

at the right level in the library stack, as well as other generally

10

useful APIs for desktop applications (such as networking and

11

D-Bus support). The goal is to overcome the shortcomings of GnomeVFS

12

and provide an API that is so good that developers prefer it over raw

13

POSIX calls. Among other things that means using GObject. It also means

14

not cloning the POSIX API, but providing higher-level, document-centric

interfaces.

</para>

<para>

The abstract file system model of GIO consists of a number of

20

interfaces and base classes for I/O and files:

<variablelist>

<varlistentry>

<term>GFile</term>

<listitem><para>reference to a file</para></listitem>

25

</varlistentry>

26

<varlistentry>

27

<term>GFileInfo</term>

28

<listitem><para>information about a file or filesystem</para></listitem>

29

</varlistentry>

30

<varlistentry>

31

<term>GFileEnumerator</term>

32

<listitem><para>list files in directories</para></listitem>

33

</varlistentry>

34

<varlistentry>

35

<term>GDrive</term>

36

<listitem><para>represents a drive</para></listitem>

37

</varlistentry>

38

<varlistentry>

39

<term>GVolume</term>

40

<listitem><para>represents a file system in an abstract way</para></listitem>

41

</varlistentry>

42

<varlistentry>

43

<term>GMount</term>

44

<listitem><para>represents a mounted file system</para></listitem>

45

</varlistentry>

46

</variablelist>

47

Then there is a number of stream classes, similar to the input and

48

output stream hierarchies that can be found in frameworks like Java:

49

<variablelist>

50

<varlistentry>

51

<term>GInputStream</term>

52

<listitem><para>read data</para></listitem>

53

</varlistentry>

54

<varlistentry>

55

<term>GOutputStream</term>

56

<listitem><para>write data</para></listitem>

57

</varlistentry>

58

<varlistentry>

59

<term>GIOStream</term>

60

<listitem><para>read and write data</para></listitem>

61

</varlistentry>

62

<varlistentry>

63

<term>GSeekable</term>

64

<listitem><para>interface optionally implemented by streams to support seeking</para></listitem>

65

</varlistentry>

66

</variablelist>

67

There are interfaces related to applications and the types

68

of files they handle:

69

<variablelist>

70

<varlistentry>

71

<term>GAppInfo</term>

72

<listitem><para>information about an installed application</para></listitem>

</varlistentry>

<varlistentry>

<term>GIcon</term>

<listitem><para>abstract type for file and application icons</para></listitem>

77

</varlistentry>

78

</variablelist>

79

There is a framework for storing and retrieving application settings:

80

<variablelist>

81

<varlistentry>

82

<term>GSettings</term>

83

<listitem><para>stores and retrieves application settings</para></listitem>

84

</varlistentry>

85

</variablelist>

86

There is support for network programming, including connectivity monitoring,

87

name resolution, lowlevel socket APIs and highlevel client and server

helper classes:

<variablelist>

<varlistentry>

<term>GSocket</term>

92

<listitem><para>lowlevel platform independent socket object</para></listitem>

93

</varlistentry>

94

<varlistentry>

95

<term>GResolver</term>

96

<listitem><para>asynchronous and cancellable DNS resolver</para></listitem>

97

</varlistentry>

98

<varlistentry>

99

<term>GSocketClient</term>

100

<listitem><para>high-level network client helper</para></listitem>

101

</varlistentry>

102

<varlistentry>

103

<term>GSocketService</term>

104

<listitem><para>high-level network server helper</para></listitem>

105

</varlistentry>

106

<varlistentry>

107

<term>GSocketConnection</term>

108

<listitem><para>network connection stream</para></listitem>

109

</varlistentry>

110

<varlistentry>

111

<term>GNetworkMonitor</term>

112

<listitem><para>network connectivity monitoring</para></listitem>

113

</varlistentry>

114

</variablelist>

115

There is support for connecting to <link linkend="http://www.freedesktop.org/wiki/Software/dbus">D-Bus</link>,

116

sending and receiving messages, owning and watching bus names,

117

and making objects available on the bus:

118

<variablelist>

119

<varlistentry>

120

<term>GDBusConnection</term>

121

<listitem><para>a D-Bus connection</para></listitem>

</varlistentry>

<varlistentry>

<term>GDBusMethodInvocation</term>

126

<listitem><para>for handling remote calls</para></listitem>

</varlistentry>

<varlistentry>

<term>GDBusServer</term>

131

<listitem><para>helper for accepting connections</para></listitem>

</varlistentry>

<varlistentry>

<term>GDBusProxy</term>

136

<listitem><para>proxy to access D-Bus interfaces on a remote object</para></listitem>

</varlistentry>

</variablelist>

Beyond these, GIO provides facilities for file monitoring,

141

asynchronous I/O and filename completion. In addition to the

142

interfaces, GIO provides implementations for the local case.

143

Implementations for various network file systems are provided

144

by the GVFS package as loadable modules.

</para>

<para>

Other design choices which consciously break with the GnomeVFS

149

design are to move backends out-of-process, which minimizes the

150

dependency bloat and makes the whole system more robust. The backends

151

are not included in GIO, but in the separate GVFS package. The GVFS

152

package also contains the GVFS daemon, which spawn further mount

153

daemons for each individual connection.

154

</para>

155

156

<figure id="gvfs-overview">

157

<title>GIO in the GTK+ library stack</title>

158

<graphic fileref="gvfs-overview.png" format="PNG"></graphic>

</figure>

<para>

The GIO model of I/O is stateful: if an application establishes e.g.

163

a SFTP connection to a server, it becomes available to all applications

164

in the session; the user does not have to enter his password over

and over again.

</para>

<para>

One of the big advantages of putting the VFS in the GLib layer

169

is that GTK+ can directly use it, e.g. in the filechooser.

</para>

</chapter>

<chapter>

<title>Writing GIO applications</title>

175

176

<para>

177

      The information in the GLib <ulink url="http://developer.gnome.org/glib/stable/glib-programming.html">documentation</ulink> about writing GLib

178

applications is generally applicable when writing GIO applications.

179

</para>

180

181

<simplesect><title>Threads</title>

182

183

<para>

184

GDBus has its own private worker thread, so applications using

185

GDBus have at least 3 threads. GIO makes heavy use of the concept

186

of a <link linkend="g-main-context-push-thread-default">thread-default

187

main context</link> to execute callbacks of asynchronous

188

methods in the same context in which the operation was started.

</para>

</simplesect>

<simplesect id="async-programming"><title>Asynchronous Programming</title>

194

195

<para>

196

Many GIO functions come in two versions: synchronous and asynchronous,

197

denoted by an <code>_async</code> suffix. It is important to use these

198

appropriately: synchronous calls should not be used from

199

within a main loop which is shared with other code, such as one in the

200

application’s main thread. Synchronous calls block until they complete,

201

and I/O operations can take noticeable amounts of time (even on ‘fast’

202

SSDs). Blocking a main loop iteration while waiting for I/O means that

203

other sources in the main loop will not be dispatched, such as input and

204

redraw handlers for the application’s UI. This can cause the application

205

to ‘freeze’ until I/O completes.

</para>

<para>

A few self-contained groups of functions, such as code generated by

210

<link linkend="gdbus-codegen"><application>gdbus-codegen</application></link>,

211

use a different convention: functions are asynchronous default, and it is

212

the <emphasis>synchronous</emphasis> version which has a

213

<code>_sync</code>

214

suffix. Aside from naming differences, they should be treated the same

215

way as functions following the normal convention above.

</para>

<para>

The asynchronous (<code>_async</code>) versions of functions return

220

control to the caller immediately, after scheduling the I/O in the kernel

221

and adding a callback for it to the main loop. This callback will be

222

invoked when the operation has completed. From the callback, the paired

223

<code>_finish</code> function should be called to retrieve the return

224

value of the I/O operation, and any errors which occurred. For more

225

information on using and implementing asynchronous functions, see

226

<link linkend="GAsyncResult.description"><type>GAsyncResult</type></link>

227

and <link linkend="GTask.description"><type>GTask</type></link>.

</para>

<para>

By starting multiple asynchronous operations in succession, they will be

232

executed in parallel (up to an arbitrary limit imposed by GIO’s internal

233

worker thread pool).

</para>

<para>

The synchronous versions of functions can be used early in application

238

startup when there is no main loop to block, for example to load initial

239

configuration files. They can also be used for I/O on files which are

240

guaranteed to be small and on the local disk. Note that the user’s home

241

directory is not guaranteed to be on the local disk.

</para>

</simplesect>

<simplesect><title>Security</title>

246

247

<para>

248

When your program needs to carry out some privileged operation (say,

249

create a new user account), there are various ways in which you can go

about this:

<itemizedlist>

<listitem><para>

Implement a daemon that offers the privileged operation. A convenient

254

way to do this is as a D-Bus system-bus service. The daemon will probably

255

need ways to check the identity and authorization of the caller before

256

executing the operation. <ulink url="http://www.freedesktop.org/software/polkit/docs/latest/polkit.8.html">polkit</ulink> is a framework that allows this.

257

</para></listitem>

258

<listitem><para>

259

Use a small helper that is executed with elevated privileges via

260

pkexec. <ulink url="http://www.freedesktop.org/software/polkit/docs/latest/pkexec.1.html">pkexec</ulink> is a small program launcher that is part of polkit.

261

</para></listitem>

262

<listitem><para>

263

Use a small helper that is executed with elevated privileges by

being suid root.

</para></listitem>

</itemizedlist>

None of these approaches is the clear winner, they all have their

268

advantages and disadvantages.

</para>

<para>

When writing code that runs with elevated privileges, it is important

273

to follow some basic rules of secure programming. David Wheeler has an

274

excellent book on this topic,

275

<ulink url="http://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO/index.html">Secure Programming for Linux and Unix HOWTO</ulink>.

</para>

<para>

When using GIO in code that runs with elevated privileges, you have to

280

be careful. GIO has extension points whose implementations get loaded

281

from modules (executable code in shared objects), which could allow

282

an attacker to sneak his own code into your application by tricking it

283

into loading the code as a module. However, GIO will never load modules

284

from your home directory except when explictly asked to do so via an

285

environment variable.

</para>

<para>

In most cases, your helper program should be so small that you don't

290

need GIO, whose APIs are largely designed to support full-blown desktop

291

applications. If you can't resist the convenience of these APIs, here

292

are some steps you should take:

293

<itemizedlist>

294

<listitem><para>

295

Clear the environment, e.g. using the <function>clearenv()</function>

296

function.

297

David Wheeler has a good <ulink url="http://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO/environment-variables.html">explanation</ulink> for why it is

298

important to sanitize the environment.

299

See <xref linkend="running-gio-apps"/>

300

for a list of all environment variables affecting GIO. In particular,

301

<envar>PATH</envar> (used to locate binaries), <envar>GIO_EXTRA_MODULES</envar> (used to locate loadable modules) and <envar>DBUS_{SYSTEM,SESSION}_BUS_ADDRESS</envar> (used to locate the D-Bus system and session bus) are important.

302

</para></listitem>

303

<listitem><para>

304

Don't use GVfs, by setting <envar>GIO_USE_VFS=local</envar> in the environment.

305

The reason to avoid GVfs in security-sensitive programs is that it uses

306

many libraries which have not necessarily been audited for security problems.

307

Gvfs is also heavily distributed and relies on a session bus to be present.

</para></listitem>

</itemizedlist>

</para>

</simplesect>

</chapter>

<chapter>

<title>Compiling GIO applications</title>

318

319

<para>

320

GIO comes with a <filename>gio-2.0.pc</filename> file that you

321

should use together with <literal>pkg-config</literal> to obtain

322

the necessary information about header files and libraries. See

323

the <literal>pkg-config</literal> man page or the GLib documentation

324

for more information on how to use <literal>pkg-config</literal>

325

to compile your application.

</para>

<para>

If you are using GIO on UNIX-like systems, you may want to use

330

UNIX-specific GIO interfaces such as #GUnixInputStream,

331

#GUnixOutputStream, #GUnixMount or #GDesktopAppInfo.

332

To do so, use the <filename>gio-unix-2.0.pc</filename> file

333

instead of <filename>gio-2.0.pc</filename>

</para>

</chapter>

<chapter id="running-gio-apps">

338

<title>Running GIO applications</title>

339

340

<para>

341

GIO inspects a few of environment variables in addition to the

ones used by GLib.

</para>

<formalpara>

<title><envar>XDG_DATA_HOME</envar>, <envar>XDG_DATA_DIRS</envar></title>

347

348

<para>

349

GIO uses these environment variables to locate MIME information.

350

        For more information, see the <ulink url="http://freedesktop.org/Standards/shared-mime-info-spec">Shared MIME-info Database</ulink>

351

and the <ulink url="http://freedesktop.org/Standards/basedir-spec">Base Directory Specification</ulink>.

</para>

</formalpara>

<formalpara>

<title><envar>GVFS_DISABLE_FUSE</envar></title>

357

358

<para>

359

This variable can be set to keep #Gvfs from starting the fuse backend,

360

which may be unwanted or unnecessary in certain situations.

</para>

</formalpara>

<para>

The following environment variables are only useful for debugging

366

GIO itself or modules that it loads. They should not be set in a

367

production environment.

368

</para>

369

<formalpara>

370

<title><envar>GIO_USE_VFS</envar></title>

371

372

<para>

373

This environment variable can be set to the name of a #GVfs

374

implementation to override the default for debugging purposes.

375

The #GVfs implementation for local files that is included in GIO

376

has the name "local", the implementation in the gvfs module has

the name "gvfs".

</para>

</formalpara>

<formalpara>

<title><envar>GIO_USE_FILE_MONITOR</envar></title>

383

384

<para>

385

This variable can be set to the name of a #GFileMonitor

386

implementation to override the default for debugging purposes.

387

The #GFileMonitor implementation for local files that is included

388

in GIO on Linux has the name "inotify", others that are built

389

are built as modules (depending on the platform) are called

"fam" and "fen".

</para>

</formalpara>

<formalpara>

<title><envar>GIO_USE_VOLUME_MONITOR</envar></title>

396

397

<para>

398

This variable can be set to the name of a #GVolumeMonitor

399

implementation to override the default for debugging purposes.

400

The #GVolumeMonitor implementation for local files that is included

401

in GIO has the name "unix", the hal-based implementation in the

402

gvfs module has the name "hal".

</para>

</formalpara>

<formalpara>

<title><envar>GIO_USE_TLS</envar></title>

408

409

<para>

410

This variable can be set to the name of a #GTlsBackend

411

implementation to override the default for debugging purposes.

412

GIO does not include a #GTlsBackend implementation, the gnutls-based

413

implementation in the glib-networking module has the name "gnutls".

</para>

</formalpara>

<formalpara>

<title><envar>GIO_MODULE_DIR</envar></title>

419

420

<para>

421

When this environment variable is set to a path, GIO will load

422

modules from this alternate directory instead of the directory

423

built into GIO. This is useful when running tests, for example.

</para>

</formalpara>

<formalpara>

<title><envar>GIO_EXTRA_MODULES</envar></title>

429

430

<para>

431

When this environment variable is set to a path, or a set of

432

paths separated by a colon, GIO will attempt to load

433

additional modules from within the path.

</para>

</formalpara>

<formalpara>

<title><envar>GSETTINGS_BACKEND</envar></title>

439

440

<para>

441

This variable can be set to the name of a #GSettingsBackend

442

implementation to override the default for debugging purposes.

443

The memory-based implementation that is included in GIO has

444

the name "memory", the one in dconf has the name "dconf-settings".

</para>

</formalpara>

<formalpara>

<title><envar>GSETTINGS_SCHEMA_DIR</envar></title>

450

451

<para>

452

This variable can be set to the name of a directory that is

453

considered in addition to the <filename>glib-2.0/schemas</filename>

454

subdirectories of the XDG system data dirs when looking

455

for compiled schemas for #GSettings.

</para>

</formalpara>

<formalpara>

<title><envar>DBUS_SYSTEM_BUS_ADDRESS</envar></title>

461

462

<para>

463

This variable is consulted to find the address of the D-Bus system

464

bus. For the format of D-Bus addresses, see the D-Bus

465

<ulink url="http://dbus.freedesktop.org/doc/dbus-specification.html#addresses">specification</ulink>.

466

</para>

467

<para>

468

Setting this variable overrides platform-specific ways of determining

469

the system bus address.

</para>

</formalpara>

<formalpara>

<title><envar>DBUS_SESSION_BUS_ADDRESS</envar></title>

475

476

<para>

477

This variable is consulted to find the address of the D-Bus session bus.

478

</para>

479

<para>

480

Setting this variable overrides platform-specific ways of determining

481

the session bus address.

</para>

</formalpara>

<formalpara>

<title><envar>DBUS_STARTER_BUS_TYPE</envar></title>

487

488

<para>

489

This variable is consulted to find out the 'starter' bus for an

490

application that has been started via D-Bus activation. The possible

491

values are 'system' or 'session'.

</para>

</formalpara>

<formalpara>

<title><envar>G_DBUS_DEBUG</envar></title>

497

498

<para>

499

This variable can be set to a list of debug options, which

500

cause GLib to print out different types of debugging

501

information when using the D-Bus routines.

502

<variablelist>

503

<varlistentry>

504

<term>transport</term>

505

<listitem><para>Show IO activity (e.g. reads and writes)</para></listitem>

506

</varlistentry>

507

<varlistentry>

508

<term>message</term>

509

<listitem><para>Show all sent and received D-Bus messages</para></listitem>

510

</varlistentry>

511

<varlistentry>

512

<term>payload</term>

513

<listitem><para>Show payload for all sent and received D-Bus messages (implies message)</para></listitem>

</varlistentry>

<varlistentry>

<term>call</term>

             <listitem><para>Trace g_dbus_connection_call() and g_dbus_connection_call_sync() API usage</para></listitem>

518

</varlistentry>

519

<varlistentry>

520

<term>signal</term>

521

<listitem><para>Show when a D-Bus signal is received</para></listitem>

522

</varlistentry>

523

<varlistentry>

524

<term>incoming</term>

525

<listitem><para>Show when an incoming D-Bus method call is received</para></listitem>

526

</varlistentry>

527

<varlistentry>

528

<term>return</term>

529

<listitem><para>Show when a reply is returned via the #GDBusMethodInvocation API</para></listitem>

530

</varlistentry>

531

<varlistentry>

532

<term>emission</term>

533

<listitem><para>Trace g_dbus_connection_emit_signal() API usage</para></listitem>

534

</varlistentry>

535

<varlistentry>

536

<term>authentication</term>

537

<listitem><para>Show information about connection authentication</para></listitem>

538

</varlistentry>

539

<varlistentry>

540

<term>address</term>

541

<listitem><para>Show information about D-Bus address lookups and autolaunching</para></listitem>

542

</varlistentry>

543

</variablelist>

544

The special value <literal>all</literal> can be used to turn

545

on all debug options. The special value

546

<literal>help</literal> can be used to print a list of

547

supported options to standard output.

</para>

</formalpara>

<formalpara>

<title><envar>G_DBUS_COOKIE_SHA1_KEYRING_DIR</envar></title>

553

554

<para>

555

Can be used to override the directory used to store the

556

keyring used in the <literal>DBUS_COOKIE_SHA1</literal>

557

authentication mechanism. Normally the directory used is

558

<filename>.dbus-keyrings</filename> in the user's home

directory.

</para>

</formalpara>

<formalpara>

<title><envar>G_DBUS_COOKIE_SHA1_KEYRING_DIR_IGNORE_PERMISSION</envar></title>

565

566

<para>

567

If set, the permissions of the directory used to store the

568

keyring used in the <literal>DBUS_COOKIE_SHA1</literal>

569

authentication mechanism won't be checked. Normally the

570

directory must be readable only by the user.

</para>

</formalpara>

</chapter>

<chapter id="extending-gio">

576

<title>Extending GIO</title>

577

578

<para>

579

A lot of the functionality that is accessible through GIO

580

is implemented in loadable modules, and modules provide a convenient

581

way to extend GIO. In addition to the #GIOModule API which supports

582

writing such modules, GIO has a mechanism to define extension points,

583

and register implementations thereof, see #GIOExtensionPoint.

584

</para>

585

<para>

586

The following extension points are currently defined by GIO:

</para>

<formalpara>

<title>G_VFS_EXTENSION_POINT_NAME</title>

591

592

<para>

593

Allows to override the functionality of the #GVfs class.

594

Implementations of this extension point must be derived from #GVfs.

595

GIO uses the implementation with the highest priority that is active,

596

see g_vfs_is_active().

597

</para>

598

<para>

599

GIO implements this extension point for local files, gvfs contains

600

an implementation that supports all the backends in gvfs.

</para>

</formalpara>

<formalpara>

<title>G_VOLUME_MONITOR_EXTENSION_POINT_NAME</title>

606

607

<para>

608

Allows to add more volume monitors.

609

Implementations of this extension point must be derived from

610

#GVolumeMonitor. GIO uses all registered extensions.

611

</para>

612

<para>

613

gvfs contains an implementation that works together with the #GVfs

614

implementation in gvfs.

</para>

</formalpara>

<formalpara>

<title>G_NATIVE_VOLUME_MONITOR_EXTENSION_POINT_NAME</title>

620

621

<para>

622

Allows to override the 'native' volume monitor.

623

Implementations of this extension point must be derived from

624

#GNativeVolumeMonitor. GIO uses the implementation with

625

the highest priority that is supported, as determined by the

626

is_supported() vfunc in #GVolumeMonitorClass.

627

</para>

628

<para>

629

GIO implements this extension point for local mounts,

630

gvfs contains a hal-based implementation.

</para>

</formalpara>

<formalpara>

<title>G_LOCAL_FILE_MONITOR_EXTENSION_POINT_NAME</title>

636

637

<para>

638

Allows to override the file monitor implementation for

639

local files. Implementations of this extension point must

640

be derived from #GLocalFileMonitor. GIO uses the implementation

641

with the highest priority that is supported, as determined by the

642

is_supported() vfunc in #GLocalFileMonitorClass.

643

</para>

644

<para>

645

GIO uses this extension point internally, to switch between

646

its fam-based and inotify-based file monitoring implementations.

</para>

</formalpara>

<formalpara>

<title>G_LOCAL_DIRECTORY_MONITOR_EXTENSION_POINT_NAME</title>

652

653

<para>

654

Allows to override the directory monitor implementation for

655

local files. Implementations of this extension point must be

656

derived from #GLocalDirectoryMonitor. GIO uses the implementation

657

with the highest priority that is supported, as determined by the

658

is_supported() vfunc in #GLocalDirectoryMonitorClass.

659

</para>

660

<para>

661

GIO uses this extension point internally, to switch between

662

its fam-based and inotify-based directory monitoring implementations.

</para>

</formalpara>

<formalpara>

<title>G_DESKTOP_APP_INFO_LOOKUP_EXTENSION_POINT_NAME</title>

668

669

<para>

670

Unix-only. Allows to provide a way to associate default handlers

671

with URI schemes. Implementations of this extension point must

672

implement the #GDesktopAppInfoLookup interface. GIO uses the

673

implementation with the highest priority.

674

</para>

675

<para>

676

This extension point has been discontinued in GLib 2.28. It is

677

still available to keep API and ABI stability, but GIO is no

678

longer using it for default handlers. Instead, the mime handler

679

mechanism is used, together with x-scheme-handler pseudo-mimetypes.

</para>

</formalpara>

<formalpara>

<title>G_SETTINGS_BACKEND_EXTENSION_POINT_NAME</title>

685

686

<para>

687

Allows to provide an alternative storage for #GSettings.

688

Implementations of this extension point must derive from the

689

#GSettingsBackend type. GIO contains a keyfile-based

690

implementation of this extension point, another one is provided

by dconf.

</para>

</formalpara>

<formalpara>

<title>G_PROXY_EXTENSION_POINT_NAME</title>

697

698

<para>

699

Allows to provide implementations for network proxying.

700

Implementations of this extension point must provide the

701

#GProxy interface, and must be named after the network

702

protocol they are proxying.

703

</para>

704

<para>

705

glib-networking contains an implementation of this extension

706

point based on libproxy.

</para>

</formalpara>

<formalpara>

<title>G_TLS_BACKEND_EXTENSION_POINT_NAME</title>

711

712

<para>

713

Allows to provide implementations for TLS support.

714

Implementations of this extension point must implement

715

the #GTlsBackend interface.

716

</para>

717

<para>

718

glib-networking contains an implementation of this extension

point.

</para>

</formalpara>

<formalpara>

<title>G_NETWORK_MONITOR_EXTENSION_POINT_NAME</title>

725

726

<para>

727

Allows to provide implementations for network connectivity

728

monitoring.

729

Implementations of this extension point must implement

730

the #GNetworkMonitorInterface interface.

731

</para>

732

<para>

733

GIO contains an implementation of this extension point

734

that is using the netlink interface of the Linux kernel.

</para>

</formalpara>

</chapter>

</part>

nexmon – Blame information for rev 1