Re: Bundle vs. Framework for plugins
Re: Bundle vs. Framework for plugins
- Subject: Re: Bundle vs. Framework for plugins
- From: "Eric Baur" <email@hidden>
- Date: Mon, 19 Jun 2006 13:12:35 -0700
On 6/19/06, Greg Herlihy <email@hidden> wrote:
On 6/18/06 9:47 PM, "Eric Baur" <email@hidden> wrote:
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.
Good point. I had realized when I started this project that I was going to
have that issue at the top (ie: ethernet vs. loopback, etc), but I thought I
would be able to handle it in those cases with one big class. I had
forgotten about the fact that some protocols can be encapsulated in almsot
anything, making the class heirarchy too restrictive. Thanks for pointing
that out.
You may wish to look at Ethereal - an open source network packet analyzer
I use it extensivly, but it is missing some features that I'd like to have.
I've already written my own sniffer app, I'm just looking to expand it's
capabilities now. (I actually looked into trying to model the way ethereal
does the disectors, but I didn't feel like restricting myself to that
model... I wanted to be able to take advantage of some of cocoa's features -
like binding - in my app.)
Though I would not describe the process of getting it up
and running as quick and convenient by any stretch of the imagination.
The fink package worked pretty seamlessly for me. It seems slow on Mac OS
X, however (compared to both Linux and Windows). Maybe it would be better
if I complied it myself. (?)
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
-
Interesting idea, but some of the things I'd like to be able to implement do
require more logic. For example, tracking a TCP conversation from start to
close. Since this logic spans multiple packets (and has various ways it can
transpire), I need to be able to store things programatically. Also, I
didn't want to restrict what a future plug in could track just because I
didn't think of something during the design phase, so I want to make it as
open as possible. (Insert witty comment about my orignial plan being overly
restrictive!)
Thanks for the input!
Eric
_______________________________________________
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