On Feb 3, 2012, at 7:51 AM, Joerg Mayer wrote:
> iOS version:
> - Probably not: Apple does not allow GPLed Software in the applestore:
> http://michelf.com/weblog/2011/gpl-ios-app-store/
...and also probably doesn't allow programs that run as root, which would be needed if the permissions on the BPF devices aren't changed, or allow the installation of arbitrary launchd LaunchDaemons, which would be needed to change the permissions on the BPF devices.
> - If not, ask the core developers how they think about git - they are the
> only ones that would be forced to interact with git, the rest could use a
> svn mirror.
For libpcap and tcpdump I've learned how to work around Git's "check in frequently" orientation (my workflow *really* matches that of CVS and SVN more than that of Git - I keep a tree around for development, do frequent checkouts and merges while developing, and check in when it's ready), so I could apply that to Wireshark as well.
> docbook:
> - can we create one paper type that is compatible with both us and a4, so
> we only have to build the pdfs once.
> - the windows help files are deprecated by microsoft but the replacement
> is not supported on xp
> - we don't have oneline help on Unix/Linux/...
> - Using a unified help format for all platforms? pdf with links?
I think the desktop environment with the #1 market share does not come with a PDF viewer by default. (It's not a UN*X-based desktop environment, if you were only including KDE and GNOME in the set of desktop environments, or even including Mac OS X.)
For the native forms of online help:
There's the old old Windows WinHelp help system (RTF-based?), and then there's HTML Help (which is presumably HTML-based), and then there's Microsoft Help 2 (not sure what it uses), and then there's Microsoft Help Viewer 1.x which, despite the "1.x", is apparently newer than "Microsoft Help 2" (XHTML-based).
Mac OS X's help system is HTML-based.
GNOME's Yelp help browser "allows you to view documentation regarding GNOME and other components through a variety of formats. These formats include docbook files, HTML help pages, man pages and info pages (support for man pages and info pages may optionally be compiled in).
I'm not sure *what* KDE 4.0 does.
If all else fails, HTML could be handed to a Web browser.
I *suspect* docbook can be translated into most if not all help-file formats, including Boring Old HTML.
> wiretap plugins:
> - plugins for reading proprietary packet formats are a good idea
> - put an example and explanation into wiretap/README.plugin
> - How to handle writing the (read-only) captures into a standard
> format? Don't know.
> - is there a 1:1 mapping between DLTs and WTAP_ENCAP_... ?
(Technically, what are in pcap files are LINKTYPE_ values, not DLT_ values; in almost all cases, the equivalent LINKTYPE_ and DLT_ types have the same numerical value, but, for historical reasons, some DLT_ types have different numerical values on different BSDs, and a separate LINKTYPE_ value was assigned for all of them to use.)
There's neither a 1-1 nor an onto mapping between them; not all LINKTYPE_ values have WTAP_ENCAP_ values (and that will probably continue to be the case at times - people may get LINKTYPE_ values assigned and either not contribute Wireshark support or contribute it after the LINKTYPE_ value is assigned), and not all WTAP_ENCAP_ values have corresponding LINKTYPE_ values (one could request LINKTYPE_ values for the missing ones, but nobody's done so).
> i10n:
> - for the GUI OK
> - for the dissectors not OK
> - if someone wants to do it: don't stop him or her
Presumably that's i10n and l10n, as the former would be needed to provide a framework for the latter. Would full l10n for some set of "first-tier" languages be considered a requirement for a major release?
