* Duncan Mac-Vicar P.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
* What to Discuss (we should meet and find solutions)
- - Namespaces, domains
This topic is still blur. We want to namespace resources, however it looks like REST convention only namespace resources if they are nested.
I do not think its a REST convention, but more an ActiveResource and Rails routing convention. See http://guides.rubyonrails.org/routing.html The way we use namespaces/domains right now is mostly driven by the close coupling Rails routing puts between URLs and controllers.
So I have a small feeling that by following to much RESTful practices we are ignoring others. If we will have /system in the url, that has to be a resource too.
Not necessarily as REST does not say anything about assembly of URLs. So having a /system/time resource is fine and does not imply anything about /system. More important are the documented URLs as they present entry points into the resource web. The current proposal for pluggable resources is to expose only a single URL, namely /yast, and have everything else reachable via hyperlinks from there.
In other parts we need to also figure good apis.
Absolutely ! This is directly related to the resource model we want to establish. This is still an open AI.
Right now stuff like patch install is broken, because the resources are automatically routed (map.resource), so stuff like "install" does not work. We have to think how are we going to handle those, at least sit down and define the few domains we will do for the start. Either we make it possible for plugged resources to handle custom actions (patches.put(:install)), making exceptions here and there, or we define more complicated ones.
I do not think is has to be more complicated if we follow a good modeling approach. map.resource tries to be 'mostly RESTful', with the exception of /new and /edit (which we don't need on the server side). I'd like to follow these conventions.
In this case I do think creating a packageinstallation resource is too-much.
A packageinstallation resource would be the wrong model. A 'software/installed' model, representing installed software, would be a better one. Installing a package would be represented by 'creating a new software/installed resource instance'. As usual, the real world puts limitations on the ideal model. Package installation is transactional and has side effects (i.e. obsoletes) which isn't really RESTful.
For example, the current automatic resource registration does not allow nested resources.
Thats rather easy to fix by moving from a static (yaml) resource description format to a dynamic (.rb files) one. Can you give a concrete example of where nested resources would help ?
The current navigation of resources is cool, but on the client makes things complicated for nested resources. You need to know the urls,
The pluggable resource implementation is all about restricting the exposed (in terms of documentation and stability) URLs to a single one in order to gain freedom and flexibility of the resource model.
- - Permissions
permissions is a nested resource of users, which is now a separate resource plugin, therefore I changed the users plugin to manually map permissions as nested. However the current permissions is highly dependent on resource names, and the whole discussion about namespaces, domains, etc makes this very inconsistent. We need to design this so we can enable it.
The inconsistency should go away as we separate the resource name from its implementation in Rails. Being RESTful means to report insufficient permissions with proper http status codes if an unauthorized access is attempted. The current use of permissions couples two modeling aspects. That of a resource and that of access rights to manage the resource. We might want to keep it that way and document it as an exception to the RESTful convention. Or we model a permissions resource, relating users to resources. This would give us more flexibility, e.g. granting rights by creating a permission resource or revoking rights by deleting a permissions resource. Klaus --- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org