I have a suggestion. In the scripts or skins preferences, it would be nice to have a "find updates" botton, almost like "Firefox addons updater feature", in the next version of msgplus!

If I'm not mistaken, it was once suggested, but refused for some reason. I could be wrong but I'm pretty sure it's come up a few times before

quote:

---

Originally posted by MattyRid
t was once suggested, but refused for some reason. I could be wrong

---

quote:

---

Originally posted by aNILEator

quote:

---

Originally posted by MattyRid
t was once suggested, but refused for some reason. I could be wrong

---

It's been suggested, and will be coming in a future version if all goes well

The problem currently is peoples personal version numbering systems, a prototype updater script for scripts and skins was made, although it worked mostly it encountered problems with various naming methods eg BETA, 1.2c, ++, *Fix* etc

---

Why restricting it to the scripts-DB? Any restriction like that will again result in many not-checkable scripts, actually just like it is now... Thus seriously flawed, imho.

---

Me thinks that what is needed is a new version tag in the ScriptInfo.xml. With a pure numerical value with whole numbers; exactly like how Plus! itself does it. And also a unique scriptID number tag.

Now, if a developer could login somewhere in a central DB (this is not the scripts-DB; let's call it an update-DB; the DB is located on one of the Plus!-servers of course). In that DB you can set a few things:

1) The script's unique value, the scriptID. This number is generated by the update-DB upon request of the developer and is of course unique. With this number you identify the script for which you can set the following update-data:

2) the latest version number (this is the pure numerical whole number value talked above, not the already existing version number)

3) the URL where the new update is located. Now this can be a link to the scripts-DB, but can just as well be a link to a 3rd party site.

this could even be moderated if security is a concearn. URLs which point to the scripts-DB are automatically accepted, while other URLs will be checked from time to time. If anything bad is detected, the script's update-data can be disabled temporarly or the developer's login can even be banned. whatever.

Also, it could automatically checked that the URL points to a webpage and not to a direct download, I think, no?.

4) the name and/or visible version number (the existing version number) of the script so an updater can show something more meaningfull if it reports that there is a new version available.

All this is actually pretty similar to how Plus! checks for an update of itself...

And this can even be made more complex by allowing scriptIDs to point to another ScriptID. In case the developer want to merge two different scripts into one with the new release for example (although this merging could be done without a "ScriptID forwarding" too).... You can do all sorts of things with a system like this, once it is in place. eg: connect the update-DB account of the developer to an account on the forum (if there is one)... etc...

With this system you give the chance to every developer to have an auto-update system for their scripts, since Plus! can check everything automatically, people could write their own updater program, etc etc. And most importantly, you do not restrict it to only scripts in the scripts-DB. On top of that you even solve the problem of having scripts with old, depricted URLs where the update is located (this is an already existing problem for some scripts btw!).


Again, any system which would limit the auto-update to only a select few scripts is not good and goes past the point of having a versatile global update system in the first place.

At one stage I had a go at something like this.  How I went about it was comparing the date that the script was imported and seeing if there is any updates to that script that happened after that date.

This method is flawed and won't give any updates that might have occured before installing, but it is at least something.

This with something that compares the version numbering that people have now should work well (at least in theory).

Though it would be better to have a more uniform system.... (but you should allow A or B or RC<number> as well IMHO)

quote:

---

Originally posted by markee
<snipped>

This with something that compares the version numbering that people have now should work well (at least in theory).

<snipped>

(but you should allow A or B or RC<number> as well IMHO)

---

quote:

---

Originally posted by CookieRevised
Why restricting it to the scripts-DB? Any restriction like that will again result in many not-checkable scripts, actually just like it is now... Thus seriously flawed, imho.

---

I don't see why something cannot be written to cope with these extra expressions.

We do this kind of stuff at work, but with much more difficult and abstract circumstances.  Regex and a little logic is all that is needed to get this to work.

If I wasn't so busy I would have a go at this myself.

I agree with Cookie, if there could be somewhere, where a script developer could generate a GUID for a script and with that GUID we are able to update information within a specific scripters database which would include information for the script latest version etc. This could be in direct correlation with the new Script DB.

For instance if I develop a script called HelloWorld. I go to a development center and login/register select to create a new script. I enter the name of the script and in turn a GUID is created. This GUID would be specific to my script and no one elses. Once this is generated I can enter details for the script and any changes are sent as an update to a Moderator of scripts on the Script DB to approve changes. To prevent spamming the only time the changes need to be approved by the Moderator would be when a PLSC is uploaded to the server. (And then subsequent changes after that would be sent to the moderator)

This would be the best option because then developers can simply login and change details of their scripts (with approval from a Moderator of course).

This way if a script has a valid GUID then Plus! can check the server for updates

quote:

---

Originally posted by matty
For instance if I develop a script called HelloWorld. I go to a development center and login/register select to create a new script. I enter the name of the script and in turn a GUID is created. This GUID would be specific to my script and no one elses. Once this is generated I can enter details for the script and any changes are sent as an update to a Moderator of scripts on the Script DB to approve changes. To prevent spamming the only time the changes need to be approved by the Moderator would be when a PLSC is uploaded to the server. (And then subsequent changes after that would be sent to the moderator)

---

Sorry, but why must this be restricted to the scripts-DB????????????????????????

I don't see any reason why it should only be done for scripts in the DB. Sorry, but that is just not right. And I don't see any reason why it can't or shouldn't be for all developers.

And inserting even more stuff in the PLSC? Why? That is really not needed at all and will eventually lead to scripts not being able to update when links change etc. Not to mention that people could be confused since you will end up with different sized PLSC for the same script, etc... And I don't want any program to insert anything in my PLSC either. And it would be hard for the user to control when there needs to be an update-check, and what about the UI of the updater? Is that all going to be included, each time, in every script on the user's computer? That's a serious waste, imho.

An update checker should be powered by Plus! itself; Plus! will handle where to read from, where the update-db is located, what to show to the user, etc. All which is required in the script itself are 2 small extra tags (the numerical version number and the GUID), nothing more. The rest is in the update-DB.

And the update-DB will not contain any PLSCs at all, just some small info like the GUID, the latest numerical version number, the URL where the new version can be downloaded from and the latest string version number, and maybe title and description to show something to the user. This makes that thousands and thousands of people/scripts can use this and it would still be fast.

Please consider this.

quote:

---

Originally posted by markee
I don't see why something cannot be written to cope with these extra expressions.

---

quote:

---

Originally posted by CookieRevised
Sorry, but why must this be restricted to the scripts-DB????????????????????????

---

quote:

---

Originally posted by CookieRevised
An update checker should be powered by Plus! itself; Plus! will handle where to read from, where the update-db is located, what to show to the user, etc. All which is required in the script itself are 2 small extra tags (the numerical version number and the GUID), nothing more. The rest is in the update-DB.

---

quote:

---

Originally posted by MenthiX
I don't really see a reason to provide autoupdate support to skins/scripts outside the DB. Not because it wouldn't be possible technically, but because Plus! in a way will be responsible for all skins/scripts that use autoupdate (they use the Plus! servers, Plus!' GUI will recommend the user to upgrade, etc.), while the quality of those downloads outside the db is hard to check... I can already imagine the posts "Plus! spreads virusses trough auto-update".

There would be a mutual benefit for submitting to the db: Developers get auto-update, users get more downloads to view at a central place and some type trustworthyness on the downloads distributed trough auto-update, i get an easier way to verify the downloads depending on auto-update.

---

The quality of the scripts outside the DB can be checked as well.

The script-db is restrictive, even for "quality" scripts, and will be even more restrictive in the future (XP/Vista issue). There are already scripts in the DB which I have big questions about, quality wise (and the voting system is just really inlogic, but that's yet another matter). You are restricting thrustworthy people because some things are not accepted in the DB.

Plus! is already "responsible" for scripts, hence why it shows the warning that a script should only be started on the user's own risk. This can (and should) very easly be extended to the auto-update. It is still the user's responsebility to download the script and it's still the user's responsebility to run the script. In fact, at it is now, a script can very easly use its own update-mechanism to do something malicous and you would have no control over it. If you extend the use of the update-DB you actually make it that you DO have control over it for the scripts which use it. Thus you actually extend the control over more scripts than just the ones in the script-DB.

Checking scripts outside the script-DB (but in the update-DB) is just as difficult/easy as checking the ones which are in the script-DB. If a script does something not good, simply remove it from the script-DB and remove it from the update-DB, exactly the same. If the user sees an update message from Plus!, he would at least know their is some form of control (no matter how small or big).

I know it is Patchou's decision in the end, but if such an update mechanism is going to, _again_ , restrict the user, I'm certainly not happy about it and believe it is a very big oppertunity which is missed. Keep it open for all scripts, or at least do not restrict the script-DB so much.

All I can think of about this right now is that it is only for some kind of elite restricted group of scripters who don't tolorate anything else.

quote:

---

Originally posted by CookieRevised
All I can think of about this right now is that it is only for some kind of elite restricted group of scripters who don't tolorate anything else.

---

• Script isn't a valid .plsc file, or submitter didn't include all the information in his mail as requested at http://www.msgpluslive.net/scripts/submit/ (submitter gets mailed back why and gets the chance to fix it).
  
• Script has code copied from another script (if submitter gets permission from the original creator it can still be added).
  
• Script doesn't contain copied code, but still does almost exactly the same as a script already in the db (can still be added if the submitter can explain why his script is considerably better or different than the old alternative).
  
• Script is malicious / highly annoys contacts... think about flooders, trojan-like scripts, obvious spamming, "hacking", etc.
  
• Script could be replaced by an existing Plus! feature or a quicktext.
  
• Simple autotalkers, bots, "wierdmakers" and random quote generators are generally only accepted if the script offers a GUI to edit/add more to the rules/quotes of the script. (this to avoid the db being flooded with this kind of scripts, if well done with an configuration panel scripts in this category are still accepted).
  
• Script has an obvious bug, preventing it from functioning under normal usage, or slowing down/crashing Messenger (submitter gets the chace to fix the error).

It Would Be Just Amazing