Scripting / SL External Communication
jetten at gmail.com
Mon Jan 21 12:26:48 PST 2008
I might be the only one who thinks this, but coming from absolutly no
programing knowledge (ok some BASIC in highschool and a bit of HTML), I've
learned quite a bit just from having to try and read and understand LSL.
It's actually given me insight and direction into creating other scripts in
other languages. To me, LSL was sort of the stepping stone. I may not be the
best scripter in the world, and I may not know how to compile my own version
of the viewer (yet). BUT I think what you are proposing salahzar, takes away
from what I think is one of the most valuable parts of LSL. It teaches you
Oh sure the syntax could be easier, and I could think of more appropriate
names for some of the functions. But I like the way it works now, and I
liked it when I first started. What's more, I think I'll be sad when phase 2
of Mono rolls around and people stop using lsl for stuff and go straight for
Mono code. It means I'll have to learn it all over again lol. But see,
that's what I love about SL. Every day is a new experience in learning (and
On Jan 21, 2008 1:46 PM, claudio pacchiega <pakkio at gmail.com> wrote:
> Kelly, since you were asking. What about a neat enhancement to hide the
> asynchronous nature of lsl scripts?
> Using all those callbacks make quite impossible very often to follow the
> real flow in an lsl script.
> What about something like:
> while (retlist=llHtmlRequest(...) != null)
> process retlist with answer from llHtmlRequest(), advancing
> where retlist=llHtmlRequest would do as syntactical sugar the async
> request and the coming back when receiving the result from the server?
> The same might apply to llRequestNotecardLine and many others.
> This might hugely improve the teaching of lsl to people who are not gurus
> And a better structuring of programs so that they can be better readable.
> On Jan 21, 2008 7:32 PM, Kelly Linden <kelly at lindenlab.com> wrote:
> > Mark Meijer wrote:
> > For such purposes, I think a better solution would be to have a decent
> > scripting system for SL, coupled with decent communication between SL
> > and external servers (and I mean decent, not the httprequest or
> > xml-rpc that they have now). Then put the core of your application on
> > your own server in whatever framework you like.
> > I'm interested in what you imagine as a "decent communication between
> > SL and external servers". I think llHTTPRequest and it's counter part *
> > SVC-1086 <https://jira.secondlife.com/browse/SVC-1086>* (not yet
> > implemented) are 'decent communication' - I've ranted about xmlrpc so won't
> > even mention it here, beyond saying that its flaws are mostly in our
> > implementation. What sort of communication do you imagine we could or
> > should enable? We are talking about cross server communication between
> > hosts that can't trust each other - what solutions do you have in mind?
> > - Kelly
> > *
> > *
> > _______________________________________________
> > Click here to unsubscribe or manage your list subscription:
> > https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters
> Click here to unsubscribe or manage your list subscription:
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the secondlifescripters