exceptions xml-rpc?

Has any one herd of ll making an exception for some one out side of LL being able to send xml-rpc? Like SLExchange, or maybe secondserver?

We at GOM have talked to LL about getting outbound XML-RPC made a priority. We've been on them enough that I'm pretty sure if they'd make an exception for anybody, they'd probably make one for us. And they haven't.

So, I'm thinking "no outbound XML-RPC" a pretty solid rule until they get the administrative aspects figured out.

SecondServer uses email pretty much exclusively (although we are moving into a hybrid setup at the moment for certain tasks), the main reasoning behind this is because XMLRPC is too constricted.

With email, you get at least 4000 bytes of data to work with, XMLRPC gives you 255 + 4. For outbound information there is very few circumstances where we use less than the maximum size of an XMLRPC packet. (Inbound has some situations where XMLRPC has started being used - mainly due to the fact it can be called synchronously, and replies back)

Ideally, we would like LL to implement something a little better suited for both situations. An idea presented was plain HTTP with POST data. This would be compatible with everything, and would not nessecarily be constricted like preset schema. (for instance, on the LSL side, work with lists for the incoming/outgoing functions/events - rather than defining: 1 integer, 1 string)

-Adam

but fields post and fetch have not be implimented yet, right?

I was wondering what your using to detect / interpret incoming e-mail. Then triggering the first ping And for the xml pinging. And how do you mange all the different possible connections at ones? I would guess sending a complete packet with all the data would be the easiest way, but it looks like that's not always possible with the current implementation of xml.

Wouldn't it be great, if when ll upgrade sls xml-rpc, that they add support for defining the values that are passed. I'm trying to teach my self xml-rpc, and I'm realizing the effect of being locked into a set xml-rpc call.

<?xml version="1.0"?>
<methodCall>
    <methodName>llRemoteData</methodName>
    <params>
        <param>
            <value>
                <struct>
                    <member>
                        <name>Channel</name>
                        <value><string>4a250e12-c02e-94fb-6d2f-13529cbaad63</string></value>
                    </member>
                    <member>
                        <name>IntValue</name>
                        <value><int>0</int></value>
                    </member>
                    <member>
                        <name>StringValue</name>
                        <value><string>test</string></value>
                    </member>
                </struct>
            </value>
        </param>
    </params>
</methodCall>

And having to pass multiple values as a value, when xml-rpc suppose be universal, by defining each value separately, and identified. So any one can retrieve, send remote calls.
I'm just thinking there must be a better way, that would allow sls xml-rpc to communicate with server and clients that haven't been designed with SLS in mind. Like the relevant information to contact the sls script being part of the url. like http://server:8000/xmlrpc.cgi?scriptKey. or some thing.
but getting to send calls is more important, but wouldn't it be great.