You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Up until now, sources have been pretty static in terms of the scopes that they could gather items from. However in the future this will no longer be the case, and we are going to need to build some new features to handle this. A good example is a theoretical Github source. In this source we might have a type called issue with a unique attribute value of 51. Now issue 51 isn't going to be unique globally, just within that repo, so the scope would need to be username.reponame or something similar.
The problem here is that new users/orgs and repos can be added all the time, so the current setup where the sources are enumerated at the beginning doesn't really make sense.
In this case we would need a source to be able to be dynamically scoped. When a users requests something in a specific scope, it would be up to the dynamically scoped source to check that it can check within the requested scope and return the correct thing. Similarly if a user makes a request with a wildcard scope (*) the dynamically scoped source would need to be able to enumerate all scopes that it knows about at the time, and search within all of them.
We are pretty close to this with the existing sdp.WILDCARD constant and Scopes() method, how it will need to be reviewed to make sure it makes sense or whether we need to add more detailed wildcard features, like having a source state that it supports the scope foo.bar.* for example
The text was updated successfully, but these errors were encountered:
Up until now, sources have been pretty static in terms of the scopes that they could gather items from. However in the future this will no longer be the case, and we are going to need to build some new features to handle this. A good example is a theoretical Github source. In this source we might have a type called
issue
with a unique attribute value of51
. Now issue 51 isn't going to be unique globally, just within that repo, so the scope would need to beusername.reponame
or something similar.The problem here is that new users/orgs and repos can be added all the time, so the current setup where the sources are enumerated at the beginning doesn't really make sense.
In this case we would need a source to be able to be dynamically scoped. When a users requests something in a specific scope, it would be up to the dynamically scoped source to check that it can check within the requested scope and return the correct thing. Similarly if a user makes a request with a wildcard scope (
*
) the dynamically scoped source would need to be able to enumerate all scopes that it knows about at the time, and search within all of them.We are pretty close to this with the existing
sdp.WILDCARD
constant andScopes()
method, how it will need to be reviewed to make sure it makes sense or whether we need to add more detailed wildcard features, like having a source state that it supports the scopefoo.bar.*
for exampleThe text was updated successfully, but these errors were encountered: