Currently we are tied into the CCSDS specification and yielding packets based upon this, but XTCE does not require this. We should try to make it easier to handle other types of packets as well, and I don't think it would be too difficult, but would involve some book keeping and renaming of classes.

We could keep our RawPacketData class with the read_* methods on it as a base class.
https://github.com/medley56/space_packet_parser/blob/d0a608dbcd18abcabb3652a7c74f6052e572079d/space_packet_parser/packets.py#L84
Then subclass this to add on all of the CCSDS header parsing stuff with a new RawCCSDSPacketData class. If there are other packet types, we could keep adding subclasses to handle different headers etc, but leave the reader up on the superclass.

Create a generic Packet class that doesn't have the header/user_data fields, very plain to store parsed content from XTCE. Again subclassing dict and allowing for our current CCSDSPacket to add those methods as a subclass.
https://github.com/medley56/space_packet_parser/blob/d0a608dbcd18abcabb3652a7c74f6052e572079d/space_packet_parser/packets.py#L278

XTCE Definition

Rather than specific parse_ccsds_packet methods, we could call this parse_packet() and allow for any byte representation to be passed in.
https://github.com/medley56/space_packet_parser/blob/d0a608dbcd18abcabb3652a7c74f6052e572079d/space_packet_parser/definitions.py#L312

The packet generator would be a bit trickier and what to do with that, because it is very much tied to a user's chosen spec and needs to know how many bytes to pull off at any given time.
https://github.com/medley56/space_packet_parser/blob/d0a608dbcd18abcabb3652a7c74f6052e572079d/space_packet_parser/definitions.py#L362

@cgobat, you mentioned you had some other formats of packets besides CCSDS that would be useful to parse, so it'd be good to hear your thoughts on what would be helpful to make this more generic and if the above seems reasonable or there are better ways to approach this.