Shoutbox

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)

---

something like this has mostly been coded
The new plusDB currently generate a GUID for the user, and it can easily generate one per script/skin plus provide an api for checking scripts too if its wanted (and if Mr MenthiX says its fine )

(It could also insert an automatic update js file directly into the plsc if needed...)

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.

---

Because the version number string can contain any text and numbers in any form. I have seen version numbers like "Alpha", "001", "1.003", "2,50", with hyphens in between, commas, text, parenthesis, whatever. It is simply not possible to use the existing version tag to make a fail-proof comparison. Using a positive whole number is the most easiest. The comparison will be fail-proof and you wont restrict people from using their own version system (nor do you need to code an extremely rediculus complex routine, which will always have shortcommings, to compare something).

quote:

---

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

---

I wasn't meaning to restrict it to the scripts db I was using it as an example it should be for both.

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.

---

That's the way i imagined it, except, the download DB would insert those values (ensuring the user didn't typo anything or used a non-unique ID). Scripters could optionally set a tag in their XML to disable autoupdate, should they want to use their own autoupdater they already created.

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.

In the end it's all up to Patchou, it's his software and servers being used for this. If he want's it, the possibillity is there, but i wonder who will be responsible for the unchecked downloads.

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.

---

Completely agree with you

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.

---

Why do you think that ? IMO the scripts DB is not very restrictive at all. The most common reasons for denying a script are:

• 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).

That's not a very small list, but i think those are reasonable restrictions for everyone. Other reasons to deny a script are very rare. You certainly don't have to be some leet coders to get in. I don't know where you base your opinion on, do you have an example of a script that got denied and you think should have been accepted?

The skins db is a bit more restrictive, where a fair amount of submits get denied because they are basically not more than a background image on the contaclist and convo windows. We try to keep a balanced amount of quality skins to show skins are really different from what Messenger already offers.


You mentioned the XP/Vista issue multiple times. Officially i haven't heard anything about that from Patch yet. We still have to talk about that once it becomes an issue. For now there is no restriction on XP-only scripts at all. In fact, i test all scripts on an XP machine... i don't even have a physical Vista machine yet myself.
If Patchou would want to filter XP-only script in a way i would suggest doing something like the compatibility info in the skins db. Eitherway, nothing has been decided around that yet (not from my side at least).


If you find serious problems with a script in the db, mail me. For bugs that don't cause fatal errors, contact the creator... I don't expect all scripts in the DB to be "bugfree" as part of not being too restrictive.

It Would Be Just Amazing