-----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.
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.
In other parts we need to also figure good apis. 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. In this case I do think creating a packageinstallation resource is too-much.
http://www.slideshare.net/calamitas/restful-best-practices (slide 28,29...) gives a good example. Rails allows to create custom methods, like /project/1/validate with PUT, which would "validate" a project. However those slides tell that one does not validate a project, but create a project-validation resource. We don't subscribe to a group but create a group subscription (therefore nested resources), one does not deactivate an account but delete an account activation. (Slide 44 is funny).
For example, the current automatic resource registration does not allow nested resources.
The current navigation of resources is cool, but on the client makes things complicated for nested resources. You need to know the urls,
- - 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.
- - packaging
While the original Makefiles are there, they are mostly duplicates.
For the users plugin, in addition to the Makefile, I have a Rakefile, which for example has a package task
desc 'Generate tarball package' Rake::PackageTask.new('www', :noversion) do |p| p.need_tar_bz2 = true p.package_dir = 'package' p.package_files.include('**/*') p.package_files.exclude('package') end
As this code will be duplicated in every plugin rakefile, we could create a kind of devtools with these tasks, because they are shared between plugins, web service and then a Rakefile would need only to require 'yast/tasks' or something.
Also, question here, why the current spec file marks directories as %config? Ie: %config /srv/www/%{pkg_user}/vendor/plugins/%{plugin_name}/app ?
- - Be more strict with conventions and naming. For example /etc/yast_user_roles is not very descriptive, specially when we already have a /etc/YaST (which we should use?: discussion).
cheers Duncan
* Duncan Mac-Vicar P. dmacvicar@suse.de [Apr 26. 2009 21:39]:
-----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)
-
Duncan Mac-Vicar P. -
Klaus Kaempf