On 06/24/2011 06:47 AM, Andreas wrote:
Am 21.06.2011 08:25, schrieb Jaap Keuter:
On 06/21/2011 07:20 AM, Andreas wrote:
Moving some dissectors to be built-in probably make sense, as the ABI
wasn't as
stable as required to guarantee compatibility with bugfix versions
(even in
stable branches).
Am 21.06.2011 08:25, schrieb Jaap Keuter:
On 06/21/2011 07:20 AM, Andreas wrote:
Moving some dissectors to be built-in probably make sense, as the ABI
wasn't as
stable as required to guarantee compatibility with bugfix versions
(even in
stable branches).
Please clarify?
I must revoke my sta
Am 21.06.2011 10:23, schrieb Roland Knall:
Now, the problems I had with the SercosIII plugin came from the fact,
that it was a plugin, and therefore its proto_register method was
called after(!) the proto_register method for the built-in dissectors.
This lead to some confusion, where the dissecto
Hi
On Tue, Jun 21, 2011 at 1:55 AM, Ulf Lamping wrote:
> Am 21.06.2011 00:27, schrieb Roland Knall:
>> There is nothing technically wrong with dissectors being developed as
>> plugins. There might be some technical questions that arise from that
>> fact, if another dissector is using them, but fo
On 06/21/2011 07:20 AM, Andreas wrote:
Moving some dissectors to be built-in probably make sense, as the ABI wasn't as
stable as required to guarantee compatibility with bugfix versions (even in
stable branches).
Please clarify?
Jaap
___
Am 21.06.2011 00:27, schrieb Roland Knall:
The reason against plugins might be, and I am just guessing here, that
everyone is talking about the same dissector if it is built-in. But
the plugin could be from a prior installation, or a different
wireshark version.
I tried to figure out for som
them as well) in terms of
architecture/API. Given the current discussion, does it make sense to start
breaking the CIP dissector up into multiple files (like Profinet) just for the
shear volume it could turn in to? For "legacy reasons" is CIP stuck as a
builtin?
-Original
Am 21.06.2011 00:27, schrieb Roland Knall:
Hi
There is nothing technically wrong with dissectors being developed as
plugins. There might be some technical questions that arise from that
fact, if another dissector is using them, but for now, those issues
seemed to be dealt with correctly (for ref
Hi
There is nothing technically wrong with dissectors being developed as
plugins. There might be some technical questions that arise from that
fact, if another dissector is using them, but for now, those issues
seemed to be dealt with correctly (for reference see the whole
openSAFETY vs. SercosIII
Am 20.06.2011 16:29, schrieb mman...@netscape.net:
(just added myself to the mailing list so I can include reply history to
the topic. This message touches on both Jaap's and Roland's comments)
As the (main) author of the PROFINET plugin I may add a few cents ...
Excuse me if I'm slightly wron
as a plugin example.
More comments any one?
Regards
Anders
From: wireshark-dev-boun...@wireshark.org
[mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of
mman...@netscape.net
Sent: den 19 juni 2011 16:59
To: wireshark-dev@wireshark.org
Subject: [Wireshark-dev] plugins to builtins
Why wou
mman...@netscape.net wrote:
>
>While I see "grouped protocols" in the current epan\dissector directory, I
>thought maybe Profinet could have its own directory off of it if otherwise
>'pollutes' the main dissector directory. I just see the plugins directory as
>"Windows only", and I don't think
(just added myself to the mailing list so I can include reply history to the
topic. This message touches on both Jaap's and Roland's comments)
Profinet and Ethercat were the 2 protocols I was most looking at to convert to
built-ins. Being in the industrial protocol space, they are (could be)
PM, Anders Broman
>> wrote:
>>>
>>> Hi,
>>> I'm not sure if we want to convert all plugins to builtin ones but the
>>> asn1
>>> plugin should stay as a plugin and I would think at least one more simple
>>> one as a plugin example.
&
Behalf Of
mman...@netscape.net
Sent: den 19 juni 2011 16:59
To: wireshark-dev@wireshark.org
Subject: [Wireshark-dev] plugins to builtins
Why would a plugin dissector ever be better than a builtin? I see
"development speed" mentioned as a plus, but isn't the lack of "platform
__
> From: wireshark-dev-boun...@wireshark.org
> [mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of
> mman...@netscape.net
> Sent: den 19 juni 2011 16:59
> To: wireshark-dev@wireshark.org
> Subject: [Wireshark-dev] plugins to builtins
>
> Why would a plugin dissect
k.org
[mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of mman...@netscape.net
Sent: den 19 juni 2011 16:59
To: wireshark-dev@wireshark.org
Subject: [Wireshark-dev] plugins to builtins
Why would a plugin dissector ever be better than a builtin? I see "development
speed" mentioned
Why would a plugin dissector ever be better than a builtin? I see "development
speed" mentioned as a plus, but isn't the lack of "platform independent code" a
much greater detriment?
Is there any reason why the current plugins couldn't be converted to built-in
dissectors? I dove in and conve
18 matches
Mail list logo
