diff options
author | Bill Meier <wmeier@newsguy.com> | 2010-04-16 17:26:47 +0000 |
---|---|---|
committer | Bill Meier <wmeier@newsguy.com> | 2010-04-16 17:26:47 +0000 |
commit | 7ab0cfa8d6444f1b319ae40036b136ac197e41af (patch) | |
tree | 930358f94fe54ff236e56dd066f688fee0fc8529 /docbook/wsdg_src | |
parent | e740706aeb919cc7921ec0c7653876cd70e0ddff (diff) |
(Trivial changes)
svn path=/trunk/; revision=32496
Diffstat (limited to 'docbook/wsdg_src')
-rw-r--r-- | docbook/wsdg_src/WSDG_chapter_dissection.xml | 6 | ||||
-rw-r--r-- | docbook/wsdg_src/WSDG_chapter_sources.xml | 12 |
2 files changed, 9 insertions, 9 deletions
diff --git a/docbook/wsdg_src/WSDG_chapter_dissection.xml b/docbook/wsdg_src/WSDG_chapter_dissection.xml index ec9909692b..eaf8b0c194 100644 --- a/docbook/wsdg_src/WSDG_chapter_dissection.xml +++ b/docbook/wsdg_src/WSDG_chapter_dissection.xml @@ -25,13 +25,13 @@ </para> <para> There is little difference in having your dissector as either a plugin - or build-in. On the Win32 platform you have limited function access + or built-in. On the Win32 platform you have limited function access through what's listed in libwireshark.def, but that is mostly complete. </para> <para> The big plus is that your rebuild cycle for a plugin is much shorter - than for a build-in one. So starting with a plugin makes initial development - simpler, while deployment of the finished code may well be done as build-in + than for a built-in one. So starting with a plugin makes initial development + simpler, while deployment of the finished code may well be done as built-in dissector. </para> <note><title>See also README.developer</title> diff --git a/docbook/wsdg_src/WSDG_chapter_sources.xml b/docbook/wsdg_src/WSDG_chapter_sources.xml index e4be5d1f3c..ee08080b36 100644 --- a/docbook/wsdg_src/WSDG_chapter_sources.xml +++ b/docbook/wsdg_src/WSDG_chapter_sources.xml @@ -850,9 +850,9 @@ Index: file.h </para> </listitem> <listitem><para> - <command>Submit dissectors as build-in whenever possible.</command> + <command>Submit dissectors as built-in whenever possible.</command> Developing a new dissector as a plugin is a good idea because compiling is - quicker, but it's best to convert dissectors to the build-in style before + quicker, but it's best to convert dissectors to the built-in style before submitting for checkin. This reduces the number of files that must be installed with Wireshark and ensures your dissector will be available on all platforms. </para><para> @@ -1074,7 +1074,7 @@ diff -c -r1.5 dlnames.c <note><title>Note!</title> <para> This action is only possible/allowed by the Wireshark core developers who - have write access to the Subversion repository. It is put in here, to have + have write access to the Subversion repository. It is put in here to have all information in one place. </para> </note> @@ -1089,7 +1089,7 @@ diff -c -r1.5 dlnames.c </listitem> <listitem> <para> - Add a line to each new file, containing the following text (case is + Add a line to each new file containing the following text (case is important, so don't write ID or id or iD): <programlisting> $Id$ @@ -1133,14 +1133,14 @@ $Id$ </para> </listitem> </orderedlist> - Don't forget a brief description of the reason for the commit, so other + Don't forget a brief description of the reason for the commit so other developers don't need to read the diff in order to know what has changed. </para> </section> <section id="ChSrcBinary"> <title>Binary packaging</title> <para> - Delivering binary packages, makes it much easier for the end-users to + Delivering binary packages makes it much easier for the end-users to install Wireshark on their target system. This section will explain how the binary packages are made. </para> |