[sphere]

The resolving part is easy. But this needs to be integrated into the repository-system. A plugin needs to register its regular expressions in addon.xml and these expressions need to be in the repositories addons.xml so that it really gets a benefit.

I agree totally with the last part (I think that's what you already posted in your thread of wishes) - love to see that. But I can't quite follow what you mean by 'repository-system'?

What can I do to push this further?

He's saying the repository needs to be aware of it so you/we can show something like "Kodi has received a call from addon X and can't handle this, to resolve this please install one of these addons: [List of Addons that can handel this]"

As a reminder lot's of things are not in Kodi or XBMC because solution proposed where not perfect and no one have better solution but nothing was chosen over something that works and fill a need.

As long as the addon system permit this (and it's the case), I do not see why this should not be pushed because maybe one day someone in 3 years will do something at core level.

This.

Exactly.
In addon.xml a plugin should be able to register itself for an url pattern. An add-on repository, like the official one is, is just (more or less) one big .xml which contains all known addon.xml.

If I attend this years devcon, I will try my best to find someone who is able to code this (or someone who explains me what needs to be done and do it myself). Just keep on posting ideas how it can be solved in the best way.

EDIT:

My current best idea is this:

Code:

<addon id="my.cool.addon">
<extension point="xbmc.python.stream_resolver" library="resolver.py">
  <regex>http://www.youtube.com\?v=.*</regex>
</extension>
</addon>

So another extension point with an "library" property to get the script plus one or multiple "regex" nodes containing regular expressions for any kind of urls.

[bromix]

...

Exactly.
In addon.xml a plugin should be able to register itself for an url pattern. An add-on repository, like the official one is, is just (more or less) one big .xml which contains all known addon.xml.

If I attend this years devcon, I will try my best to find someone who is able to code this (or someone who explains me what needs to be done and do it myself). Just keep on posting ideas how it can be solved in the best way.

EDIT:

My current best idea is this:

Code:

<addon id="my.cool.addon">
<extension point="xbmc.python.stream_resolver" library="resolver.py">
  <regex>http://www.youtube.com\?v=.*</regex>
</extension>
</addon>

So another extension point with an "library" property to get the script plus one or multiple "regex" nodes containing regular expressions for any kind of urls.

Okay..I wasn't quite sure, but I can't agree more now I try to compile some stuff together, so we keep this thing running.

Sorry for answering so late, but I was on a trip and after that I had to handle the membership for team KODI. Do we discuss this topic in this thread or should we move?

[Martijn]

Do we discuss this topic in this thread or should we move?

You can keep it here

[Lunatixz]

I agree totally with the last part (I think that's what you already posted in your thread of wishes) - love to see that. But I can't quite follow what you mean by 'repository-system'?

What can I do to push this further?

He's saying the repository needs to be aware of it so you/we can show something like "Kodi has received a call from addon X and can't handle this, to resolve this please install one of these addons: [List of Addons that can handel this]"

As a reminder lot's of things are not in Kodi or XBMC because solution proposed where not perfect and no one have better solution but nothing was chosen over something that works and fill a need.

As long as the addon system permit this (and it's the case), I do not see why this should not be pushed because maybe one day someone in 3 years will do something at core level.

This.

Exactly.
In addon.xml a plugin should be able to register itself for an url pattern. An add-on repository, like the official one is, is just (more or less) one big .xml which contains all known addon.xml.

If I attend this years devcon, I will try my best to find someone who is able to code this (or someone who explains me what needs to be done and do it myself). Just keep on posting ideas how it can be solved in the best way.

EDIT:

My current best idea is this:

Code:

<addon id="my.cool.addon">
<extension point="xbmc.python.stream_resolver" library="resolver.py">
  <regex>http://www.youtube.com\?v=.*</regex>
</extension>
</addon>

So another extension point with an "library" property to get the script plus one or multiple "regex" nodes containing regular expressions for any kind of urls.

+1

[natethomas]

I think the only reason to make it core would be for speed purposes, which, if that's really a concern or becomes a concern, I think this would make a nice candidate for one of the early binary addons eventually that actually ship with Kodi, since it definitely seems like something that may need a fair amount of updating over time.

edit: With that said, whatever it ends up being, it definitely seems like something that ought to ship with Kodi.

[takoi]

I think the only reason to make it core would be for speed purposes, which, if that's really a concern or becomes a concern, I think this would make a nice candidate for one of the early binary addons eventually that actually ship with Kodi, since it definitely seems like something that may need a fair amount of updating over time.

edit: With that said, whatever it ends up being, it definitely seems like something that ought to ship with Kodi.

The problem is more that because it itself is a plugin, it has to load every other addon from the file system every time it's opened. That's not something a binary addon would solve. In core you can be kept a routing table in memory so it's not an issue.

[sphere]

The problem is more that because it itself is a plugin, it has to load every other addon from the file system every time it's opened. That's not something a binary addon would solve. In core you can be kept a routing table in memory so it's not an issue.

I dont know the implementation but a similar system is already there: Plugin URLs.
XBMC/Kodi Core has a list of known plugin urls (e.g. "plugin.video.youtube/"). It even already asks the user if a plugin should be installed. This system only has to be extended to look for regular expression.

[Razze]

I don't think that speed will be a problem, but some hard data would be nice. If we run into a speed problem its probably down to having to ask every plugin.

[Razze]

On the other hand the resolving of an url to display supported addons might really cause trouble.
You would essentially need to ask the repo for all regexes of every addon and test them against the link we got.

The only way to get around this would be that the sending addons have to declare which format of URLs they are sending. Then we could build up an index when a repo change was done.

But this also removes some of the magic from it

[bromix]

Important
I refer to the uri2addon only as a proof of concept or some kind of test-dummy....I have no intention to resolve the whole issue with this addon.

uri2addon is parsing each installed addon...it's pretty fast...but I don't know what it takes if we have to check against a repository with more then 300 addons (and multiple repositories). There is the possibility that the addon (uri2addon) caches the information and only falls back on a re-check and after a failed re-check falls back on a check against the repository if none cached registration was found.

But the addon route fails I think with the installation of an addon? An addon can't install another addon right? That's why we should also go the core route? Also the addon can't display a proper dialog with the addons in it with the basic information and thumbs, fanart, and so on...

One question ahead...how should the call look like? What is the URI is this is a core implementation? The raw URL?

[takoi]

On the other hand the resolving of an url to display supported addons might really cause trouble.
You would essentially need to ask the repo for all regexes of every addon and test them against the link we got.

The only way to get around this would be that the sending addons have to declare which format of URLs they are sending. Then we could build up an index when a repo change was done.

But this also removes some of the magic from it

We already store addon metadata in a database. Just do the same for the expressions. Checking ~800 addons in memory is nothing

[bromix]

This is a really simplified version of a Flow-Chart...but it's something to begin with (I think/hope) and can be updated in the progress.



1.) How we call the URIs?

In my example it was based on an addon, so we got:

Code:

plugin://script.uri2addon/.....

But if this is a core element, should we try to call the raw URL like this?:

Code:

http://youtube.com/watch?v=XXXXXXX

2.) Finding an addon

I think sphere already got some ideas on that and think it makes sense to extend the addon.xml. The structure has to be discussed.

2.1.) local

I think this is the first step? Try to check an URI against the already installed addons. If more addons match, we provide a selection for the user.

2.2.) via repo to install

Theoretically the same routine as in 2.1 but only in the repository to find an addon or addons to install. Display a nice dialog with all the information of each addon (like the basic installation of a addon)

3.) no addon found

Finally KODI could display a message if an URI isn't supported at all. Now KODI does nothing if I send something with KORE or Yatse to KODI


Again, this is simplified, there is a lot to do I think (especially I don't know the sources yet). But I would try to create and work with small parts which will result in a solution of the whole thing.

[bromix]

On the other hand the resolving of an url to display supported addons might really cause trouble.
You would essentially need to ask the repo for all regexes of every addon and test them against the link we got.

The only way to get around this would be that the sending addons have to declare which format of URLs they are sending. Then we could build up an index when a repo change was done.

But this also removes some of the magic from it

We already store addon metadata in a database. Just do the same for the expressions. Checking ~800 addons in memory is nothing

Yeah

[Razze]

On the other hand the resolving of an url to display supported addons might really cause trouble.
You would essentially need to ask the repo for all regexes of every addon and test them against the link we got.

The only way to get around this would be that the sending addons have to declare which format of URLs they are sending. Then we could build up an index when a repo change was done.

But this also removes some of the magic from it

We already store addon metadata in a database. Just do the same for the expressions. Checking ~800 addons in memory is nothing

Yes, but that would mean one of two things:
1. You have to download the whole metadata of the whole repo into the clients memory. Keep small machines in mind and also it's likely it will never need 50% of these so we downloaded them just to throw them away.
2. You can do it on the server. Then it's nothing as you said, but if you do the check again and again for every kodi user that asks the repo it adds up to quiet some time of computing wasted.

[takoi]

Yes, but that would mean one of two things:
1. You have to download the whole metadata of the whole repo into the clients memory. Keep small machines in mind and also it's likely it will never need 50% of these so we downloaded them just to throw them away.
2. You can do it on the server. Then it's nothing as you said, but if you do the check again and again for every kodi user that asks the repo it adds up to quiet some time of computing wasted.

I think you vastly underestimate how tiny numbers we are talking about here. The whole repo is a few KBs in memory, tops! It's approximately nothing Did you know we currently download every translation for every addon, then immediately throw away everything but one? That is wasting bandwidth

I think we're sidetracking here though. Looking up in repo is 'nice to have' feature. the most important part is to find a nice api and a nice way to hook into the player and get it working.