> This has been on our list for a long time, and is coming close to getting
> worked on. You, can help by providing your thoughts on how it should be done.
>
> Specifically:
>
> - should we introduce handles that would work across profiles (essentially,
> you can assign a role to a handle, and then modify that handle as necessary)
> - if we were to increase the power of certain roles (technical contact
> control of NS's for example), how should we introduce this? How should we
> deal with legacy roles of this type - extend them the same power
> automagically, or require that they specifically ask for the new role type
> - how important would providing support for existing handles at other
> registries be? would it be worth supporting this considering the large
> complexities it would introduce to development?
> - what works well now, what stinks, and what must you have in a new system?
One thing: do NOT break the old stuff! It took quite a while for us to develop
our own handle system :-) Basically the admin contact should have right to
modify _anything_.
Here is what we have (a possible implementation, I mean) in a few words:
- users can create handles for themselves - that is, a user with a username and
password is created (users table)
- all domains are assigned 3 fields: admin contact id, billing contact id,
technical contact id (domains table)
- permissions:
- the admin contact can change the 3 above fields: who to associate with the
domain
- the technical contact can set the DNS data
- the billing contact receives billing info
- any users can log in and change their personal data: all domains are updated
with these data once there is a change in user data (an automatic script logs
in, changes all domains one by one...)
I do not say that that is what OpenSRS should do, but this is what we needed so
sort of programmed into our interface. Obviously this is only a subset of the
implementation.
Actually I still think that the best way would be if OpenSRS released some
documentation with direct access to all sort of data in their system, and then
separatedly release some client implementations. I do not like the idea of
having handles and stuff at the (OpenSRS) server side. I do not even like the
idea of profiles. Leave that to the client side - which is a server side from
the registrants point of view anyways. This is something like names4ever do:
they give their resellers an XML based interface to access their database, and
that's it. A much more flexible approach, and you don't have to rewrite
(=localize) text in 2600 lines long CGIs, interface PERL-scripts with your user
database, change everything if there is a new client code released, and so on
and so on... Obviously some less guru-like folks will have problems with that,
but that's why I recommend two totally separated interfaces: one low level XML
magic, and one client code released.
Now flame me, I am a worm.
- Csongor
