Current state
RequestV2 class is insanely long and its main method (answer) has ~1000 lines of code with massive amount of if / else statements. It is highly unreadable and hard to debug such method
Todo
if / else blocks into separate methodsXML_HEADER, SOAP_ENCODING_HEADER and SOAP_ENCODING_FOOTER over and over againGoal
Improve readability and debugging of the class.
@SubJunk I can take care of it. Are you interested with such contribution? If not just close this issue.
@drakulis it seems promising. Just do it. 馃憤
@SubJunk in the end I think that is time to decide if the UMS will use the old implementation or the Netty which is set as default and not confuse users with those two options.
@drakulis yes this is a good idea
@valib yes let's at least remove the old one from the GUI, if not remove it entirely
OK, so refactoring such big class will be a challenge and it will be very easy to break something during this process. Additionally reviewing the changes in PR would be a nightmare.
So I will do it in few steps and create PR when I finish each of them. Currently I see following:
createResponse method to avoid adding XML_HEADER, SOAP_ENCODING_HEADER and SOAP_ENCODING_FOOTER over and over againsearchHandler methodimageResourceHandler, mediaReceiverRegistrarHandler, getSystemUpdateIdHandler and othersfileHandler (movie, music etc). This one will be tricky.ContentDirectoryHandler, ConnectionManagerHandler etc)All the changes above will be done in the RequestV2 class. After that we may think about extracting separate, single responsibility classes from it.
Yes I really like having small pull requests for reviews, it keeps it moving along much faster and safer
@drakulis are you just taking a break or is this abandoned? I'm happy to leave it open if you're taking a break, no rush :)
@SubJunk just a break. I have tough project right now and I have to focus on it completely.
Cool, no problem. See you when you get back :)
Most helpful comment
OK, so refactoring such big class will be a challenge and it will be very easy to break something during this process. Additionally reviewing the changes in PR would be a nightmare.
So I will do it in few steps and create PR when I finish each of them. Currently I see following:
createResponsemethod to avoid adding XML_HEADER, SOAP_ENCODING_HEADER and SOAP_ENCODING_FOOTER over and over againsearchHandlermethodimageResourceHandler,mediaReceiverRegistrarHandler,getSystemUpdateIdHandlerand othersfileHandler(movie, music etc). This one will be tricky.ContentDirectoryHandler,ConnectionManagerHandleretc)All the changes above will be done in the
RequestV2class. After that we may think about extracting separate, single responsibility classes from it.