Can you be a little more specific about what you are trying to do? Are you using the AkamaiBasicStreamingPlugin to connect to another CDN? What does the URI look like that is being parsed incorrectly?
I'm just trying to understand how to customize the way the url is parsed in order to make it work with different CDNs. As it is explained in the ‘Too many private methods, constants and variables ‘ post I cannot just extend the URL or FMSURL classes and override the desire methods.
The documentation suggests that the intent is that you can customize the parsing. Can you explain how it should be done?
I was asking about the URI format you are using because I'm wondering if the incorrect parsing is due to a bug in the parsing classes. If so I'd like to fix it. FMS URI's have a standard format like this:
I know there are FMS installations that do some interesting things with URL's, for example Akamai uses an '@' character in the stream for a live stream id. So my point is, if the problem you are having is with a fairly common format for a URI, maybe we should modify the parsing code to handle it. If it's a rare format, then I think we need to change the access modifiers on some methods.
If the parsePath method on the FMSURL class were protected would that serve your needs?
Sorry, I did not explain my situation clearly, was a bit tried.
I’m using the standard URI format. It does not seem to be a bug in the parsing classes. Once the url is in the correct format and I set the useInstance to true everything parses correctly.
The use case is when attempt to support a legacy url I need to parse out the stream name modify it and put it back together. Then I pass it off to the FMSURL class where it gets parsed again. It would be more efficient if I could extend FMSURL and somehow modify the way it parses. This does two things, it prevents parsing the url twice and keeps the process inside the cdn plug-in so the end developer will not have to add additional coding to modify a legacy url that may get passed to the player. The plug-in will do it for them. I think this is more of a rare format situation. Not certain making the parsePath method protected is the best solution. What do you think?
Sounds like there are two problems here: the need for duplicate parsing, and the need to keep the parsing isolated to the plugin so that the player doesn't need to be aware of it. For the first, although duplicate parsing is indeed inefficient compared to the approach you outline, I'm skeptical that it has any noticeable effect performance-wise. One of the main reasons URL and FMSURL are not designed for extension is that we don't want to see a proliferation of URL formats/variations/parsers. So although we could consider making the URL classes more "read-write", doing so would need to be balanced against the potential for fragmentation of URL standards. If creating a second instance of the URL doesn't work for your case, please let us know (and why).
On the second point, I believe it's possible to keep all parsing logic isolated to the plugin, even if the URL itself needs to change midway through the load operation. See post with example code here, as I believe it's addressing the same problem that you're having.
Thank you very much for the feedback. I can work with that.