Conversation
|
If this is intended for extensions to be able to use shouldn't it also add |
There is a bit of a misunderstanding here. This API is internal to the app, and will stay like that. However the current MainAPI will be expanded in the future. Right now we have a function called loadLinks But this API is very limited, given that it can only return subtitles + video links. It is also a chore to handle, given that all functions has to pass two arguments. Instead my current plan for CloudStream includes writing a custom callback object that has several functions on it. This would solve the problem of future-proofing it, and making it easier to use. This is a dummy sketch of what I mean // Open so an extention can override with its own when passing it around between extractors/other things
open class MainCallback(
protected val subtitle_callback: (SubtitleFile) -> Unit,
protected val link_callback: (ExtractorLink) -> Unit,
protected val stamp_callback: (SkipStamp) -> Unit,
protected val log_callback: (String) -> Unit,
protected val crash_callback: (Throwable) -> Unit,
) {
// Multi callback by writing the same function for different data
fun invoke(data : SubtitleFile) { subtitle_callback(data) }
fun invoke(data : ExtractorLink) { link_callback(data) }
fun invoke(data : SkipStamp) { stamp_callback(data) }
// Logging
fun w(data : String){ log_callback("WARNING $data") }
fun i(data : String){ log_callback("INFO $data") }
fun e(data : String){ log_callback("ERROR $data") }
fun d(data : String){ log_callback("DEBUG $data") }
// Log throwables too
fun t(data : Throwable){ crash_callback(data) }
}Where the provider would only implement open suspend fun loadLinks(data : String, callback : MainCallback)or even open suspend fun loadLinks(callback : MainCallback)where callback has the function .data() on it. This would also solve the logging problem, as logs calls write to a global log without any connection to from where it came from. Right now the log is just filled with garbage so finding extractor specific problems is a chore, but if we link the logging like this, then we could write error UI for developers to check when loading links. Like " However, this will be fully ironed out in an upcoming PR redesigning the "loadLinks" function. |
|
Oh that sounds amazing. I understand now. Thanks a lot for the clarification! |
This is an response, addition and refactor of #2599 to make it easier to maintain and extend. The exact API is not finalized, but given that this is mostly internal it should be fine. At least until we add the ability for extensions to add SkipStamp in the loadLinks function.
Note that this is only lightly tested, but it should work fine given that it simply ports the code to the new API.