Mailinglist Archive: yast-devel (39 mails)

< Previous Next >
[yast-devel] discussion points for restful api
  • From: "Duncan Mac-Vicar P." <dmacvicar@xxxxxxx>
  • Date: Sun, 26 Apr 2009 21:40:19 +0200
  • Message-id: <49F4B8A3.7080806@xxxxxxx>
-----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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iEYEARECAAYFAkn0uKMACgkQzR62qWZ+QtF+wQCfQ0CEMgBEJhraanNiA1Hp/PTA
JQsAoL142mAcy7PpAg3NXew8qPJJjfHj
=2ynS
-----END PGP SIGNATURE-----
--
To unsubscribe, e-mail: yast-devel+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: yast-devel+help@xxxxxxxxxxxx

< Previous Next >
Follow Ups