Wireshark-users: [Wireshark-users] Re: Should the "export as text" item be in an "Export Human-re
----- Start Original Message -----
Sent: Sat, 19 May 2012 16:33:07 -0700
From: Guy Harris <guy@xxxxxxxxxxxx>
To: Community support list for Wireshark <wireshark-users@xxxxxxxxxxxxx>
Subject: Re: [Wireshark-users] Should the "export as text" item be in an
"Export Human-readable..." item in the File menu?
>
> On Apr 9, 2012, at 8:31 AM, Jaap Keuter wrote:
>
> > On 04/07/2012 06:05 AM, Guy Harris wrote:
> >> The mistake that caused this question to be asked:
> >>
> >> http://ask.wireshark.org/questions/10000/how-to-get-the-txt-file-back-to-wireshark
> >>
> >> might be due to people thinking that the result of an "Export" operation is something that contains the raw data from the packets and thus can be read into Wireshark. (The question itself appears to have hoped that, even if it couldn't be read into Wireshark, it still contained the raw data, which, in this case, it didn't.)
> >>
> >> Perhaps we should put the Export menu items for "as text" and "as PostScript" under a top-level menu item that more clearly indicates that the result of the operation will not be readable by Wireshark and can't necessarily even be converted into something readable by Wireshark?
> >>
> >> The same applies for the "export as CSV" and "export as XML" operations; those aren't easily human-readable, but they're written in a form intended for programs *NOT* interested in the raw packet data (and not equipped to parse raw packet data) to process.
> >
> > I can see the "Export / Import complementary" line of thinking (maybe I shouldn't have created the Import...). Anyways, this cannot end up in yet another top level menu, it's just not that sort of thing, it is a "File" operation.
>
> Sorry, I didn't make it clear - by "top-level menu item" in
>
> > Perhaps we should put the Export menu items for "as text" and "as PostScript" under a top-level menu item
>
> I meant a menu item under the File menu.
>
> In any case, I've thought about it a bit more, and think it might make sense to have, in the File menu:
>
> Export Packet Dissections
> Text...
> PostScript...
> CSV...
> PSML...
> PDML...
> Export SSL Session Keys...
> Export Objects
> HTTP...
> DICOM...
> SMB...
>
> rather than just "Export" as a top-level menu item - i.e., replace the "Export" top-level menu item with the three items that are currently underneath it, and give the Export->File item a name that indicates that what it exports is the result of dissection.
>
> They all "export" in the sense that they write out something other than the raw packet data, but they're all *very* different operations (the first group writes out, in non-capture-file formats, the result of packet dissection, whether it's the summary, details, or both, possibly with the raw data dumped in hex/ASCII format for text and PostScript; the second group writes out session keys from the capture; the third group writes out objects transferred over the wire by various protocols).
>
> The items under "Export Packet Dissections" would have longer descriptions similar to what they have now (I'm too lazy to type those in).
Would classifying the asymmetric export (ones that lack a corresponding "import" action) formats as "reports" help clear up the original ambiguity/misunderstanding? It seems that most of the gui-based network tools I'm forced to periodically interact with rely upon that term with at least some success.
> ___________________________________________________________________________
> Sent via: Wireshark-users mailing list <wireshark-users@xxxxxxxxxxxxx>
> Archives: http://www.wireshark.org/lists/wireshark-users
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
> mailto:wireshark-users-request@xxxxxxxxxxxxx?subject=unsubscribe
----- End Original Message -----
