XML-RPC or bust!

If you want this to be the best release 'yet', you'll need to enable XML-RPC.

I have a good 5000+ LOC which will go untested without XML-RPC enabled. So, like, pretty please give me the url for the preview grid?

last time i checked, this is not possiable.. preview has no server for xml or email, it realy is just a login + asset server syetem with a few grid machines. So will you please let the donkey go, its getting tiresum

You may want to reconsider your input in this discussion.

a) how can SL expect us to test 1.6 if we do not have access to 1.6 functionality?

quote: "help us make this the best release yet", i think the MOTD said.

Without the ability to do a full regression, that just ain't going to happen.


b) I'm sure adding another server isn't that challenging, or adding another process to a server.

Tiresome or not, when 1.6 gets released and there are problems surrounding XML-RPC or surrounding code that would have been tested if we had access to XML-RPC you're going to hear a lot of I told you sos..

And if I hear someone say "oh but we didn't really change anything so there probably won't be a problem.." then they should be demoted from software engineer to QA tester. Any with 5+ years experience in this business knows those are famous last words...

Blaze, -

it's disabled for security reasons, if someone finds a GOM terminal on the preivew grid, and pays L$10,000 into it, then that has translated into main grid L$.

If it were to be added, Email should be completely disabled so the connection cannot be initiated, and XMLRPC keys must be manually tested and used.

-Adam

Ah, come on Adam.

You're telling me Zeppi can't check the sender email for the keyword 'preview' in it?

Whatever needs to get done - get it done. Releasing software without testing it first is not acceptable development procedure..

Do we want another 1.5 fiasco on our hands, or have we already forgotten what happened?

I dont remember 1.5 breaking outbound email or incoming XMLRPC...

I also know from experience that pushing out features which are likely to cause security issues is always a bad idea when there is not a significant gain (especially when the gain is temporary). Let's assume person X runs a ATM system and decides to take a holiday for a week while LL decides to enable outbound comms for testing. I imagine when this person arrives back they might be mildly agitated at this.

Likewise, people are not going to want to change their code to block off the preview - I know I dont want to have to do it, especially on short notice.

-Adam

Adam, have you ever shipped software professionally?

On a dot release, you do a full regression. I've never worked for a company that didn't. Well, I have, and very few times we didn't do a full regression we have always paid the price.

Are you saying that 1.6 should go live without GOM fully testing itself on the preview grid?

I'm sorry, if that's the way GOM works, then they have only themselves to blame when there are problems.

The problem with 1.5 was that it got pushed out the door without full testing. I am suggesting that XML-RPC goes live so we can all test our fairly extensive suite of products on the preview grid before it goes live.

Besides, I thought the *whole* point of waiting forever for all of these changes is because they branched the tree so they didn't risk shoving out new bugs.

When you branch like this, if you don't do a full regression, then what was the point in waiting? Why didn't they just shove out the bugs and we all test as we go?

blaze blaze blaze, nobody listens anymore. you should email Phil!

Your right blaze, i should have not been to sharp with my reply, but then again did the point that some people test this stuff befor it gos into production on the preview grid?
(Any one with a FIC comment can cram it)
LL has fully explained why 1.5 was released the way it was and what they learned from it, but looking at yor posts you seem to have missed this infomation.

Allthough Inbound xml could beusefull, id prefer the lindens worked on what was being released other then messing about with servers that 90% of people dont have access to all the time.

ROFL that pretty much sums up my thoughts on FIC

--Jack Lambert

How would someone "find" a GOM terminal on the preview grid? Wouldn't GOM (or whatever provider) have to put up their terminal themselves? (And hopefully, they get some location ID information from their terminals...)

Security considerations are important, but eventually it will be necessary to allow things like XML-RPC on multiple grids - such as if/when SL software ends up being licensed to other hosts. (All licensed servers could be wired into the same grid, but I'd assume that at times splits would occur like on IRC... so in practice there would end up being multiple grids... This is another topic though )

On 1.6, as I've mentioned elsewhere, I am interested in whether Unicode strings can be taken by the XML-RPC (or email) mechanism. If not, this really curtails any scripting that could be done with Unicode characters at this point. (listen() successfully picks up Unicode strings and llSay will echo them, so a lot of manual input when a script is reset might be a partial work-around).

Anyway, if Unicode _is_ supported by the XML-RPC and email mechanisms, it definitely ought to get some testing.

I just want to help QA!

Jeez. Never seen a company that turned away free QA...

(But I think LL will release XML-RPC into preview before they go live. They are sensible folk..)

I may have missed something... But does XML-RPC change at all in 1.6? I thought it was to be exactly the same as 1.5... So what exactly will you be testing?

XML-RPC, and its interaction with Unicode.

A dot release usually demands a full regression which usually means testing functionality that hasn't changed.

Besides, I have a lot of other code that will get tested as well. I'm sure if the gigas, slexchange, gom, etc etc folks also tested their code (they can't without xml-rpc) then we'd really pound 1.6 before it went live.

I find it difficult to believe that this is not something LindenLab wants.

We can't go around complaining about SL breaking our code, etc etc if we don't even bother testing our code before they try to go live.

Heh, gigas and most other big groups have allready tested there code in 1.6, without email and xml.

they tested code without testing it. wow!

But, whatever. Maybe 1.6 will be perfect and there is no need to test everything. That happens all the time.

Sarc? right?

That's impossible. If any of the "big group's" scripts even minutely used email or XML-RPC, then you *cannot* say that they tested their scripts fully.

If anyone with an automated funds transferring device hasn't already implemented the proper security measues to prevent something like preview money transfers, then well... that just moves them one step closer to incompetancy.

SL is a digital world, GOM, IGE and others who use outbound email/RPC communication must realise that their ATM machines can be copied into a beta test. Its not fair to everyone else who needs to test their scripts under the new version.
==Chris

Chris copied into a beta test by whom? LL? Or....??


_/_/

It really doesn't matter, my point was that, because SL is a digital medium, owner's of ATMs must take special precautions to differentiate between those that are valid and those that may be copies (take into account location on the grid, simulator hostname of the sim the ATM is in, etc).
==Chris

The big problem there is that the terminals ARE identical in all ways concerned. I use public key encryption (plus a hashing method) on my payment boxes now, but the scripts do have the same private key loaded into them on preview, as they would on the mainland, which makes them look identical (although, I do doubt they would work anyway since they route through another object on the main grid, which would likely be inaccessible.).

Pooling off the email from address is not a security measure I personally make, since those can be spoofed with ease. That would be a change that would have to be forced in, which requires both significant advanced notice, and isnt something that is an ideal check.

Personally, I'd rather that the email (outbound) interface was setup in a certain manner that makes it completely incompatible with existing setups. (say requiring all preview outbound email addresses to be called [email]preview.normalname@domain.tld[/email], or requiring the MTA to be running on a nonstandard port.)

-Adam

I think the point I'm trying to make can be summed up in a sentance:

Security compramising features that are applied retroactively should never be opt-out.

-Adam

QA environments should have flags denoting what they are when ambiguity can occur.

A version # in the email sent out is probably the smartest idea. This could allow for rolling releases as well.

Soft rollouts would go a long way to avoid taking everyone out everytime they want to make a change and screw up.

But what boggles my mind, is not that this isn't happening, I can understand time pressure / lack of budget / etc.

What boggles my mind is that we are even having this debate. All of us, or at least any of us with professional software development experience, should know that this is basic software engineering 101.