This is somewhat hacky and there may be a better way to do some of it. The main problem is I wanted to de-dupe all the code for parsing generic resource stuff out (especially as I would need to dupe a lot for these additional types). Primarily this is the function formatGenericMessageResource and formatFileResource intermediate parsers.
I looked at several options, but am open to suggestions as I could not find a great one. One was change the top level interfaces to classes, so we could construct them without having to specify all args upfront. This had the downside we would have to re-declare all the interface properties on the class leading to duplicate code there. We could change all of the interfaces (for example Resource, MessageResource, MediaGenericFile ) to classes from the bottom up, this solves having to redeclare interface items. Without doing classes we cannot partially declare an interface. To solve this I initialize a generic resource, then cast it to a higher type in each type. Of course this doesn't stop you from forgetting a parameter that you should be setting, but I don't have a great solution for that (even classes would allow you to not set something). Classes would also mean you can't use the {} syntax to declare them, but rather set properties manually (unless we made constructors which would be less good given all the args). One could do an interface containing both the base type and extended properties separately. IE: MessageResource{resource: Resource; } this is bad as it makes the end user more confused during refactors, and requires them to use sub-interfaces on items for no reason.
The best option may be converting everything to classes to avoid the odd casting, let me know if you want it refactored this way (or another).
Not sure if we want to rename events? Signal/Flamingo is basically an incoming call notification but is named weirdly...
I left some debug code commented out in there that I generally find myself re-adding often. Likely a better logging system to allow easier tweaking of debug levels would probably be good (have used bunyan before).
FYI (not sure if documenting this somewhere is a good idea):
An Event/Call event will happen when a call is started (type started) (either accepted by a party or missed) and then when the call is ended (type ended). This is both for incoming and outgoing calls. A Signal/Flamingo will happen on an incoming call request (ring basically). The rest of the types should be fairly obvious. There may be more, these are the more common ones I saw.
Some minor BOM fixes.
This is somewhat hacky and there may be a better way to do some of it. The main problem is I wanted to de-dupe all the code for parsing generic resource stuff out (especially as I would need to dupe a lot for these additional types). Primarily this is the function
formatGenericMessageResourceandformatFileResourceintermediate parsers. I looked at several options, but am open to suggestions as I could not find a great one. One was change the top level interfaces to classes, so we could construct them without having to specify all args upfront. This had the downside we would have to re-declare all the interface properties on the class leading to duplicate code there. We could change all of the interfaces (for example Resource, MessageResource, MediaGenericFile ) to classes from the bottom up, this solves having to redeclare interface items. Without doing classes we cannot partially declare an interface. To solve this I initialize a generic resource, then cast it to a higher type in each type. Of course this doesn't stop you from forgetting a parameter that you should be setting, but I don't have a great solution for that (even classes would allow you to not set something). Classes would also mean you can't use the {} syntax to declare them, but rather set properties manually (unless we made constructors which would be less good given all the args). One could do an interface containing both the base type and extended properties separately. IE: MessageResource{resource: Resource; } this is bad as it makes the end user more confused during refactors, and requires them to use sub-interfaces on items for no reason. The best option may be converting everything to classes to avoid the odd casting, let me know if you want it refactored this way (or another).Not sure if we want to rename events? Signal/Flamingo is basically an incoming call notification but is named weirdly...
I left some debug code commented out in there that I generally find myself re-adding often. Likely a better logging system to allow easier tweaking of debug levels would probably be good (have used bunyan before).
FYI (not sure if documenting this somewhere is a good idea): An Event/Call event will happen when a call is started (type started) (either accepted by a party or missed) and then when the call is ended (type ended). This is both for incoming and outgoing calls. A Signal/Flamingo will happen on an incoming call request (ring basically). The rest of the types should be fairly obvious. There may be more, these are the more common ones I saw.