[texworks] Automatic update of resources

[Stefan Löffler]

Hi,

On 2011-01-21 09:43, Jérome Laurens wrote:
> Le 20 janv. 2011 à 07:55, Stefan Löffler a écrit 
>> Since there are no shared resources at the moment, every user either has
>> his/her own resources, which should get updated whenever the respective
>> user runs a new version of Tw, or central shared resources (via the
>> portable mode), which would then have to be updated by the sysadmin.
> This is suitable for resources which only depend on a static context.
> Unfortunately, no resource is absolutely static, even images.
> They may change (and should change) from time to time.
> Of course things like latex resources are more static than TW scripts,
> this is why TW always should have both a private resources repository, a shared resources one and a personal one.
> I agree that this is not straightforward, the first step is to define a proper API to ask for resources and settings,
> which implementation just redirects to the actual one.
> The next question is how would it cost to convert the actual code to conform to the advanced API ?
> No simple answer, but is can be done progressively with no harm.
> Then once everything is converted, the implementation of the advanced API can change.

Such an API should indeed be implemented. But this will take a fairly
long design process, so don't expect anything soon (i.e., before 0.4).

>> [...]
>> Regarding the above-mentioned issues:
>> As long as the user can only add new definitions/settings, everything
>> should be fairly straight forward. The problems emerge when the user
>> should also be able to modify and/or remove/disable settings in the
>> system-wide resources. For example, suppose the system-wide resources
>> define a setting A, which the user wants to unset. Writing "A=" could
>> not be distinguished from actually setting A to an empty value (which
>> may not be the same as unsetting A in some circumstances). This would
>> require a diff-like file format, which is not particularly
>> user-friendly, however. Or how would you disable/override a system-wide
>> template, which is a file of its own? An empty file is something
>> completely different from no file at all.
> About settings, it is not a good idea to use things like "A=" because they render the code difficult to read.
> Prefer things like "A=0", "A=NO", "A=''", "A=Undefined".
> In your example, you have 2 different tests
> 1) whether A is set or not
> 2) when A is set, what is the value
> In that case, the code must conform to the logic: a boolean for 1) and a value for 2)
> Merging the logic by using 2 settings instead of 1 will render things difficult to debug.

OK.

> Concerning the file problem: how can we disable/override/overwrite a system-wide file.
> - The easiest: to overwrite a system wide file
> - Less easy: override a file
> this is relevant for things like settings files. For them you can open all the setting files in a definite order and return the first occurrence of the setting in that list.

Yes, that was my idea as well. However, defining such a definite order
is not easy, I think. Especially because there are two cases that would
require reversed sequences:
a) a sysadmin wants to provide reasonable defaults/customized
extensions; in that case user settings should take precedence
b) a sysadmin wants to restrict certain things (e.g., changing the
corporate's template, or changing some scripting permission settings,
...); in that case, the system-wide settings must take precedence.

> - worst case: to disable a file, you must define a dedicated setting "List of ignored files". The default value of this list is void.

According to your statement before (don't mix the existence of a
settings with its value), there would be no alternative to this, would
there?

>>> It may allow to install the app on a movable drive.
>> And in portable mode, the situation gets worse. Does the user want to
>> relocate only his personal directory (~Library/...)? Or run Tw fully
>> portable (i.e., override /Library as well)? What if the sys-admins wants
>> to relocate the global directory (e.g. to /Tw)? Or the sys-admins wants
>> to relocate the user's directory (say, to a network share, or even a
>> virtual/dynamic directory)?
> If the user runs Tw from a usb drive, we can assume that there is no Tw available on its machine.
> Everything should be "run" from/to the usb drive, ignoring whatever is on the machine.
> Tw should focus on "standard" situations.

Unfortunately (or maybe fortunately?), portable mode is used not only
for running Tw from an USB drive. For example, it is also invaluable for
testing without risking corruption of the "normal" resources.
And even if you run from an USB drive, the following statements could apply:
a) you may want to make use of features on your system, e.g. corporate
templates
b) the sysadmin still doesn't want you to breach security, e.g. by some
escalated scripting priveledges.

Cheers,
Stefan