Digging deeper into the smackx.jingle code I’m growing suspicious that the current version is designed largely with XEP-0167 in mind.
Where I first started encountering challenges was in a seemingly core abstract class “JingleMediaManager” whose abstract method “createMediaSession” offers PayloadType in the signature. Well, I’d love to extend JingleMediaManager, but my description won’t have a PayloadType. I think the idea is right for JingleManager to handle routing the candidates and descriptor to an extendable handler. But unfortunately, the abstraction still seems too specific to
XEP-167.
I’m reviewing the relatively new specification for file transfer (XEP-0234) which doesn’t seem to mesh very well. For example, there are some differences (granted the specification is currently in an experimental state) in the description node. Unfortunately, much of the current framework seems to assume “payload-type” is relevant. In XEP-234 there is no such thing. Also for XEP-234, I’d need to specify the file I’m offering to OutgoingJingleSession, or review the file being offered in JingleSessionRequest before making a decision to accept or reject the session.
Anyway, I realize this is an open source project and fully intend to do my part here. But, there are three things that would be a huge help. One, if someone knowledgable about smackx.jingle can confirm my concerns and reassure me that I’m thinking clearly about this. Two, does anyone have any advice about how I should proceed? And of course, mad-funky hacks are always welcome.
FWIW, my proposal is to use an abstract Description class, then use concrete implementations like RTPDescription (replaces PayloadType) and FileDescription. So for example, JingleMediaManager would then have the abstract member:
createMediaSession(Description d, final TransportCandidate remote, final TransportCandidate local, JingleSession jingleSession)
Many thanks to anyone that reads this.