On Fri, 2009-08-14 at 09:27 +0200, Joerg Barfurth wrote: > Brian Cameron schrieb: > > > + /usr/bin/ck-seat-tool [--add --session-type=SESSION_TYPE > > --display-type=DISPLAY_TYPE [--seat-id=SEAT_ID] [variables...] > > | --delete --session-id=SESSION_ID] > > > > - How are seat ids chosen if not explicitly specified, for example when > using gdmdynamic or for XDMCP sessions? If --seat-id is not given, the console-kit-daemon will start a new seat for this session. The seat-id will be next available seat number. Normally is /org/freedesktop/ConsoleKit/Seat#.
> > It appears that there is some persistent state associated with seats via > seat-ids. Currently this is the case through ck-history, but the display > manager may maintain more per-seat state in the future. I do understand what you mean here. ConsoleKit is maintaining seat formation, display manager does not. What more states need in the future? > If seat-ids for dynamic seats are simply assigned using linear numbering, > that will > cause spurious association of data across unrelated seats. Yes, it is true. ck-seat-tool offers user feasibility to create sessions rather than static write configuration files. I do not see any issue for the time being. > > - What are the constraints for the SEAT-ID argument? > > For the same reason as in the previous item, a client like Sun Ray will > want to use seat ids that do reflect their internal notion of client > identity. > > The API documentation says that a seat ID is a DBus object path, but all > the sample tool output uses names like 'Seat1' to identify the seat. The SEAT-ID could be full name of a seat object path (/org/freedesktop/ConsoleKit/Seat#) or a short name (Seat#). ck-seat-tool is able to append the prefix "/org/freedesktop/ConsoleKit/" if give the short name. Regards, Halton.
