[Gnumed-devel] Workplace refactoring

[Jim Busser]

Presently the options for switching among sets of plugins  
(workplaces) are:

1. alter the selections within the workplace GNUMed default, save  
this new configuration, and then open a new client. This is a cheat,  
since instead of switching *among* pre-defined workplaces, it  
*alters* an existing workplace which then creates problems if other  
users wish a different combination.

2. insert a single workplace name into a backend server level, or  
machine level (?), or user level gnumed-client.conf file
--> the problem here is how, at the worker level, to over-ride when  
moving between different machines other than by having a personal  
user account (and therefore having to logout and login) under each  
machine?

The following was said in January... how would it be implemented that  
a GNUmed user (who was not logging or logged into the machine as a  
system user) could have attached to their GNUmed login a set of  
plugins to be used *separately* from (over-ride) any workplace, if  
one had been specified?

On 4-Jan-08, at 4:00 AM, Karsten Hilbert wrote:

> ... The other facet of this is that in the code options can be
> defined to user OR workplace independant for lookup. Such
> that if a workplace-independant option is set in one
> workplace by a user and is looked up under the same user but
> with a different workplace it is still found and reused. If,
> at some point, the user would chose to explicitely set that
> option under the second workplace that value would take
> precedence - for that workplace.


At the wiki page CustomizingBackendLogin there is a specification for  
profiles... is there a solution here to define multiple profiles,  
each of which could reference the same database but a different  
workplace, so that in this way the workers could choose (via the  
login window of the client that is being opened) which workplace to  
select? Or does the transfer S(torage and management) of workplaces  
into the backend thwart this approach?