Re: Bundle vs. Framework for plugins
Re: Bundle vs. Framework for plugins
- Subject: Re: Bundle vs. Framework for plugins
- From: Greg Herlihy <email@hidden>
- Date: Mon, 19 Jun 2006 06:28:17 -0700
- Thread-topic: Bundle vs. Framework for plugins
On 6/18/06 9:47 PM, "Eric Baur" <email@hidden> wrote:
> I started writing a plug in interface for my application, but I ran
> into a small hiccup... and I'm not sure if the way I solved it is okay
> (from a best practices standpoint), so I thought I'd run it by the
> list and see what anyone else thought.
>
> Basically, I'm writing an application that decodes network traffic. A
> packet may have an ethernet frame that encapsulates IP, which may
> encapsulate TCP, etc. I started out (internally) using sub-classes
> for each type. So, I have a TCPPacket that inherits from IPPacket
> that inherits from EthernetPacket. This works great, since each layer
> only has to implement things that are unique to it.
Modeling network packets as a class hierarchy looks great initially, but
inevitably breaks down. Not all kinds of network packets fit into a class
hierarchy. A Domain Name Service protocol (DNS) packet for example can be
either a UDP or a TCP packet. A class hierarchy will require two classes to
represent a DNS packet therefore - even though a DNS packet is logically
just one type of packet.
The core problem is that a DNS packet should not inherit from either a UDP
or a TCP packet. When one class inherits from another - it means that an
instance of the derived class can always replace an instance of the base
class. Inheritance models substitutability - not encapsulation. But since a
DNS packet is sometimes a TCP packet and other times a UDP packet - it must
be neither. Conceptually the TCP or UDP packet is used to transport (that is
encapsulate) the DNS packet - but otherwise it makes no contribution to the
interpretation of the DNS packet itself. In other words inheritance when
applied to network packets winds up treating distinct packets as alike and
alike packets as distinct.
> The problem I ran into was when I started using bundles for plugins.
> If TCPPacket and IPPacket are in different plugins, then I get a link
> error, since the super class isn't present. I can solve this by
> changing the plugins to frameworks instead of bundles, but do I loose
> anything by doing that? I'm I misusing the concept of frameworks?
> (Eventually, I'd like to have custom preference views / data views in
> NIB files within the plug in as well... I'm worried that I'll run into
> more problems down the line with this as well.)
You may wish to look at Ethereal - an open source network packet analyzer
that recognizes 759 different network protocols via code modules (called
packet dissectors) that individuals have contributed. It is possible to
build and run Ethereal as an X11 program on Mac OS X (and looks halfway
decent to boot). Though I would not describe the process of getting it up
and running as quick and convenient by any stretch of the imagination.
Since network packets all conform to one format or another, it should be
possible to describe a network packet statically, say in an XML document. If
that were done, it would not be necessary to write a custom plug-in at all -
rather the main application could simply read this description file and use
its contents to parse the network packet itself. After all, writing 759 data
files would still be a lot of work - but it would be a lot less work than
writing 759 plug-ins - even Cocoa plug-ins.
Greg
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden