I had some code that would write met-data out to a script, it was to preform
a revert if the script was edited in such a way to cause a metadata conflict
with script id (i1146).  A simple way to look at this problem would be
custom includes that were user defined are @user_include, these are then
maintained during script update, I'd prefer something more cryptic like
%include or +include, some way to make metadata lines stick through an
update, maybe even blocked from being in a script that's installing.  There
are other ways to know if a script was user included to store an attribute
in XML.  To the developer it doesn't matter if all their includes are listed
as user included in xml, since removing a user include is still very much
possible.  In any case it was the opposite function of readmetadata that I
created and it worked pretty great as far as I tested I was hoping it would
be used on this problem.  I wasn't happy that this would be happening but
there wasn't much that I could do to stop it.  As long as we know we are
dealing with opinions then one can expect all sorts of conflicts.  When
someone believes something is wrong if they aren't adversarial enough then
problems slip through and compound.  Some scripts ask their users to add new
includes, it may be a small number, but if someone does a lot of work on
includes then it can be a major issue doing it again, especially if they
still loose it the next time, I thought this would severely discourage
updating scripts since some level of trust about update capability could
have easily been lost, since updating script you would never loose the
include, the script author might encourage it while also encouraging custom
includes, making the author seem insane for suggesting that if nothing else.
 At this point many people will not update certain scripts again, or might
complain to the author.  A feature such as update all scripts seems very
dangerous at this point.

-- 
You received this message because you are subscribed to the Google Groups 
"greasemonkey-users" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/greasemonkey-users?hl=en.

Reply via email to