Greasemonkey: Deixe o servidor entregar um script que nunca será (automaticamente) atualizado

<strong i="5">@updateURL</strong> about:blank + <strong i="7">@downloadURL</strong> about:blank deve fazê-lo (pelo menos era possível desativar as atualizações automáticas usando isso no GM 3.x).

updateURL e downloadURL não são suportados para 4.x.

Na 3.x, usamos apenas os controles AOM padrão para isso.

No 4.x ainda não temos atualizações automáticas, então teremos apenas que incluí-las como um recurso básico, assim que o fizermos.

Colocar <strong i="5">@downloadURL</strong> none alinharia com o que está planejado para 4.x?

Oh, acabei de perceber que você está dizendo que deseja que o servidor que entrega o script diga ao GM que não deve atualizar o script. (Opa, não cheguei ao final da descrição ...)

Não há planos de ler / usar o valor de qualquer propriedade @...URL no GM 4. Não posso prometer nada até que o código de atualização finalmente seja escrito, mas algum tipo de cabeçalho HTTP é melhor do que tentar alterar a fonte do script.

OTOH se TM oferece suporte a um valor nenhum, sempre há compatibilidade a ser considerada.

O OP diz:

O URL de instalação inclui um parâmetro que indica a versão.

A partir disso, presumo que os parâmetros de consulta são efetivamente permalinks para scripts de usuário específicos. Também é mais provável que qualquer funcionalidade de atualização automática / verificação de atualização use o downloadUrl salvo internamente (que é apenas o URL da instalação inicial). Com alterações mínimas, acredito que podemos oferecer suporte a essa forma de permalink, adicionando correspondência de parâmetro de consulta ao detectar scripts de usuário. Conseguido adicionando *://*/*.user.js?* ao ouvinte user-script-detect.run.js .

Oh, acabei de perceber que você está dizendo que deseja que o servidor que entrega o script diga ao GM que não deve atualizar o script.

Sim, exatamente.

algum tipo de cabeçalho HTTP parece melhor do que tentar alterar a fonte do script

Greasy Fork armazena os scripts no banco de dados e reescreve a fonte de qualquer maneira (por exemplo, gera um meta.js a partir de um user.js). Mudar a fonte não é um problema para mim. Os cabeçalhos HTTP podem ser um problema, pois os scripts podem estar passando pelo software de cache.

A partir disso, presumo que os parâmetros de consulta são efetivamente permalinks para scripts de usuário específicos.

No meu jargão, o parâmetro version fornece um permalink para uma versão específica de um script de usuário específico.

Acredito que podemos oferecer suporte a essa forma de link permanente adicionando correspondência de parâmetro de consulta ao detectar scripts de usuário.

Greasy Fork não usa parâmetros de URL para nenhuma outra finalidade além de vincular a versões específicas, mas não posso prometer que não o fará no futuro, ou que outros sites também não.

Após reflexão adicional: Levaria mais esforço para ser compatível com vários mecanismos ( @derjanb , @ gera2ld), mas: Se vamos deixar a verificação de atualização do controle de origem, estou pensando mais nas linhas de uma nova entrada * tal como:

// <strong i="7">@updates</strong> never
// <strong i="8">@updates</strong> 24h
// <strong i="9">@updates</strong> 7d

Deixe o script especificar a freqüência com que deve ser atualizado automaticamente. Quando estou em desenvolvimento ativo, posso mantê-lo baixo; quando ficar estável, posso ajustá-lo (mas voltar para baixo se / quando eu começar a atualizar novamente). E um host de script pode (se ele for munging o script de qualquer maneira) sobrescrever o valor como achar melhor (com base em coisas como quantos usuários o instalaram, recursos do servidor, etc.).

Gostaria de um nome mais descritivo, mas ainda não tenho um candidato específico que goste.

* Embora para o valor never, o suporte <strong i="14">@downloadURL</strong> none também pode ser adicionado.

Do ponto de vista técnico, deve ser sth. como @updatefrequency (muito longo?) ou @updatecycle .
E, com sorte, haverá um gatilho para iniciar uma verificação de todos os scripts manualmente ...

Deixe o script especificar a freqüência com que deve ser atualizado automaticamente. Quando estou em desenvolvimento ativo, posso mantê-lo baixo; quando ficar estável, posso ajustá-lo (mas voltar para baixo se / quando eu começar a atualizar novamente). E um host de script pode (se ele for munging o script de qualquer maneira) sobrescrever o valor como achar melhor (com base em coisas como quantos usuários o instalaram, recursos do servidor, etc.).

Parece razoável.

Gostaria de um nome mais descritivo, mas ainda não tenho um candidato específico que goste.

Talvez @updateInterval ?

ou simplesmente @updatetime ... (não muito exato, mas cativante)

@updatetime me faz pensar em "às 8h" em vez de em uma frequência.

@Sxderp Então você apoiaria <strong i="6">@updatefreq</strong> 1d ?

Não sou um falante nativo, mas o valor (ou seja, 24h) não é realmente uma frequência. É um intervalo ou um período, certo? 🤓

<strong i="5">@updateinterval</strong> 1day parece bom. Eu não recomendaria "ponto final", pois tem um significado sobrecarregado em inglês comum (embora tenha um significado científico preciso)

@updateinterval é tão impreciso quanto @updatetime . Você não está interessado no intervalo, mas no intervalo de tempo (máximo) entre as atualizações ...

Eu realmente não gosto de lapso, então minha próxima sugestão seria <strong i="5">@updatespan</strong> 1d ...

@arantius , quando a atualização automática será agendada? Não consigo mudar para 3.x no FF60.