[mythtv] milti-user subsystem

Anastasiya Soboleva agsoboleva at yahoo.com
Wed Jun 7 21:16:18 UTC 2006


I have learned all messages that I have received on a problem of the multi-user subsystem for MythTV. So I offer more detailed description of my understanding of this problem.
   
  Introduction   
  Of cause, to make anything well, it is necessary to understand all over again an essence of a problem and to formulate it. So I want to formulate behavior MythTV in conditions multi-user. 
   
  Developing multi-user subsystem has appeared not simple, especially, for designing because there are many variants of the organization multi-user subsystem. There are many problems, which will be difficult to solve. So I suggest consider the following two variants. They seem to me the most interesting.
   
  First variant.
  In each moment of time MythTV knows, who works with it. Using this information MythTV knows, what the user can do, and what can’t. This can be implemented through using of a method ‘login’ - ‘logout’. The similar method is used in operating systems so it is already well-known and clear to many people. However here there are also problems. For example such:
   
  - People have not got used to work with the TV as with PC, therefore necessity ‘login’ - ‘logout’ can frighten them.
  - If some persons are watching the TV at the same time (for example in family where there are familiarity relationships between members) operations ‘login’ - ‘logout’ will be undesirable.
   
  However in big not well acquaint with each other society (as neighbors or colleges living\working at same building but in different areas) multi-user system cannot work without ‘login’ - ‘logout’.
   
  Second variant.
  It is supposed, that there are only certain operations which demand to determine who at present time interacts with MythTV (who has pressed the button). Thus it is possible to ask PIN (as in a mobile phone). If PIN is entered truly than authentication is correct and the user can continue the operation. This way has disadvantage when the number of operations demanding PIN is quite large. It becomes very difficult for the user (because user must enter PIN very often).
   
  I think, that first variant most suitable in our case. So I specify its behavior in detail.
   
  1. After MythTV installation by default only one user (root) will be exist. All operations will be carried out from its name. Externally it will be not as multi-user but as normal (as single user) usual MythTV interface. 
  2. If the user want, he would able to add other users (to specify name, rights, etc.) into MythTV. I think, that he can make this locally, however in a consequence it is possible to implement this operation as remote.
  3. If MythTV contains a lot of users than as frontend starts, it is possible to do follows (depending on MythTV settings). 
      - MythTV suggest to enter login (a name and a password) or to select login from the list, if more that one users usually work with frontend.
      - For the user who usually uses frontend only for itself better to use his login automatically.
  4. MythTV will use account logged user until the user will logout. Besides it is necessary to show a name of the current (logged) user on the screen and to show the information about current (logged) user by pressing the certain shortcut key (button)
  5. As Initiator of logout should be the current (logged) user. For this purpose he presses the appropriate shortcut key (on keyboard) or button (on remote control). After this MythTV changes mode to ‘guest’. Minimum count of operations is accessible in this mode (for example, channel view only). I think there is no necessary to organize screen lock because it is burden for the user.
   
  Account for user will allow to organize current user context in MythTV. It means, that each user can fully control his data and fulfils allowed operations (depend on permissions).
   
   
  Permissions   
  Permissions are stored in ACCOUNTS.permission field in the form, which has been offered by Chris Pinkham.
   
  This is not a complete list, just an example, and the list of permissions can easily be expanded later.  Permissions would be additive, never negative so root has all bits turned on.
   
  0x00000001 - edit normal settings _only_
  0x00000002 - edit advanced settings _only_
  0x00000003 - edit all settings
  0x00000004 - edit users (add/delete/etc.)
  0x00000010 - create new scheduled recordings (for self)
  0x00000020 - delete scheduled recordings (for self)
  0x00000040 - edit scheduled recordings (for self)
  0x00000100 - create scheduled recordings (for all)
  0x00000200 - delete scheduled recordings (for all)
  0x00000400 - edit scheduled recordings (for all)
  0x00001000 - user can run plugins
  0x00002000 - user can watch any recordings in their
               recording group (see TV ratings description
               below).
  .
  .
  .
  0xffffffff - all-powerful user, a.k.a. root
   
  When the situation specified in the list above appear MythTV checks corresponding bit in current user context permission. If bit is equal 0 operation is forbidden, otherwise - it is allowed.
   
   
  Shared records   
  Other problem is shared resource. Here it is necessary to describe what method of sharing most suits for MythTV.
   
  The shared resource list can be organized by 2 methods.
   -  As the separate (independent) list “Shared”. To view it the user should press the appropriate button.
   -  As addition to the main user playlist. The user can view among his records in playlist records what belongs to others (shared records).
   
  In multi-user subsystem we can allow user to choose list representation as one of this two variants.
   
  Here some methods of access control in shared resource are described.
  1. Common shared resource list without access control. Access to this list has all users. Therefore records, which they wish to make accessible, one needs to place in this list. Then it is necessary to inform other users that record to be in this list and to specify its name.
   
  2. Common shared resource list with access control. This method differs from previous only that each record in the shared resource list has own ACL. This ACL specify permissions for concrete users. For example, this ACL, can look like 
  ID1 - xxxx, ID2 - xxxx, …, IDi - xxxx
  Where IDi is an user account identifier (userid) for which the rights are set, xxxx is a set of the rights (Each character indicates, one of rights R-read, W-write, E-rename etc). 
  In this case resource is accessible only for that users, whose account’s ID presents in ACL and it gives the appropriate rights. It is necessary to store ACL either in the resource or in the table connected to it.
   
  I think, that for MythTV it is possible to use the second variant.
   
  I have tried shortly to explain my understanding of a problem multi-user subsystem for MythTV. I will be glad to receive your thoughts about it. Of course, exists too many different variants how to design and develop multi-user subsystem. And we can have this discussion for ages But I should choose something one to continue coding. 
   
  I already checkout code from svn and began write Account class, based on Account table.
   
  In next letter I am going to explane why user groups can be needed and how developed concept can satisfy current MythTV users demands and needs. 
   
  Anastasiya 

 __________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mythtv.org/pipermail/mythtv-dev/attachments/20060607/cd7b5858/attachment.htm 


More information about the mythtv-dev mailing list