-----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