| 103 | == Using hard coded profiles |
| 104 | As mentioned on [https://tracinsy.ewi.tudelft.nl/pubtrac/GeniusWebProfilesServer#Getafilteredprofile the profilesserver wiki page] you can easily generate a partial profile out of an existing utilityspace. A big advantage of this is that [#Visualizingresultsinolderlogfiles the result plotters] can hack out the filter and use the utilityspace that the profile was generated from to show "hypothetical" utility values. However there are reasons not to do this, for example |
| 105 | * A party getting the URL can easily hack out the filter option to gain access to the utilityspace |
| 106 | * Every time a websocket is created to the URL, a new, different filtered profile is generated. This may not fit the use case. |
| 107 | |
| 108 | Of course, profiles can also be written by hand to avoid this. However if that is done, [#Visualizingresultsinolderlogfiles the result plotters] can not apply this convenient trick anymore. |
| 109 | |
| 110 | If you want a hard fixed profile but keep the trick used by the results plotters to remain working, an easy hack can be applied: |
| 111 | * create the utilityspaces that reflect your idealized/hypothetical profile to be used by the result plotters |
| 112 | * [Download filtered profiles programmatically https://tracinsy.ewi.tudelft.nl/pubtrac/GeniusWebProfilesServer#Downloadingaprofileprogramatically] or write them by hand and store these on the server under a hashed name preventing recovery of the utilityspace name. |
| 113 | * run the parties with these hashed profiles |
| 114 | * after the run completes, manually edit the log files, replacing the hashed profilename with the original utilityapsce name. Make sure you make a backup of the log file, in case you screw up the replace. |
| 115 | * view the modified log file using the [#Visualizingresultsinolderlogfiles existing-log viewer] |
| 116 | |
| 117 | |