On Jan 30, 2008 7:57 AM, Yuval <email@example.com
5. Personally, I've had mixed experiences. It's a good tool, and I
really know not what I would have done without it. However, I think the
main development thrust is geared towards different protocols than the
one I use. Its potential is huge but, currently, you run into its
limitations very quickly (e.g. the state machine). For me it was the
connection initialisation scenario on the server side (global instead
of per-connection). The documentation is not comprehensive so you're
never quite sure if you run into a limitation or a misunderstanding
(I've had quite a few misunderstandings...). On the other hand, there's
really no alternative that I could find.
First, this was one of the challenge we had: more and more protocols to test, and a need for agility to add protocols, as well as consistency when using the tool (and report results), whatever the protocol. That's the requirements we had for Seagull. Which, more than a Diameter test tool, is really a test tool framework for (m)any protocols.
It's architecture and code base is not that simple to assimilate for a potential contributor, but it should be close to trivial to add the support of a new protocol, given that it is a declinaison of a protocol family taken into account by Seagull.
To date, the contribution provided for Seagull were around Protocol Dictionaries (the best way to start). We will try to do an extra effort to document some key areas where we think it should be easy to contribute, like:
- Adding more "actions" in the scenarios,
- Opened interfaces to control Seagull: there are some nice GUIs to develop by leveraging those (and even integrate Seagull in environments like Eclipse),
- Keys to understand to add new protocol families
The thing is that the development effort you see happening is guided by internal needs. But we still have the willingness to support any improvements or contributions that would help Seagull expand its scope.
So, as always, contributors (code, doc, tutorials) welcomed!