Some code was posted easier:
http://jira.secondlife.com/browse/SNOW-9
Philip Rosedale wrote:
Hmmm. We're spending more time on this in conversation than the time
required to write the code, I fear. Bummer.
___
Policies and (un)subscribe
Argent Stonecutter wrote:
On 2009-05-29, at 17:44, Philip Rosedale wrote:
Hmmm. We're spending more time on this in conversation than the
time required to write the code, I fear. Bummer.
Welcome to big program design.
Seriously, for something of this scale where you're designing
On 2009-05-29, at 17:44, Philip Rosedale wrote:
> Hmmm. We're spending more time on this in conversation than the
> time required to write the code, I fear. Bummer.
Welcome to big program design.
Seriously, for something of this scale where you're designing
protocols that will need to be don
I don't agree that the amount of time required to implement this is
terribly important since the amount of time required to maintain any
feature over it's lifetime is roughly an order of magnitude greater. We
might have spent quite a bit of calendar time so far but I don't think
that anybody ha
Hmmm. We're spending more time on this in conversation than the time
required to write the code, I fear. Bummer.
Well, practically speaking, we've got an intern starting who is going to
write some code to try to do this thing. If our team does this, we will
do it as best we can and get some
My personal recommendation would be JSON (could even be LLSD structures
serialized to JSON) over a TCP pipe. All of the infrastructure is already
there in the viewer.
John
On Fri, May 29, 2009 at 3:08 PM, John Hurliman wrote:
> UDP is a poor choice for creating pipes between applications. I don'
I agree. UDP was a arguably bad choice for second life in the first
place, with the exception of for the object / avatar update messages.
TCP for RPC.. definately :)
~Tom
John Hurliman wrote:
> UDP is a poor choice for creating pipes between applications. I don't
> know how OSX behaves, but th
UDP is a poor choice for creating pipes between applications. I don't know
how OSX behaves, but the networking stack in the flavors of Linux I'm
familiar with and all versions of Windows are designed to drop UDP packets;
even on the loopback connection. When you hit a certain frequency of message
d
Philippe Bossut (Merov Linden) wrote:
> Hi all,
>
> Gee! This is quite a thread! Thanks for all the suggestions, ideas and
> passion. As always, this community shows it's full of talented (and
> opiniated) people :)
>
> Since I'll be the guy tagged with driving/mentoring the intern on this
>
Melinda Green wrote:
> Dzonatas Sol wrote:
>> Attached is the basics of what is needed to get the gesture tracker
>> to listen to a port and react. For now, I've left out the XML server
>> socket bits and just cut it down to minimal code. The XML server
>> socket works, I just don't want to conf
Dzonatas Sol wrote:
> Attached is the basics of what is needed to get the gesture tracker to
> listen to a port and react. For now, I've left out the XML server
> socket bits and just cut it down to minimal code. The XML server
> socket works, I just don't want to confuse that with the request t
Hi Philippe,
On Tue, May 26, 2009 at 1:16 AM, Philippe Bossut (Merov Linden) <
me...@lindenlab.com> wrote:
> Gaze tracking: Often mentioned so that's certainly a misnomer in our
> case: we'd like to track "what the user is looking at" rather than
> "what the mouse is pointing to" (as it is today
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Philippe Bossut (Merov Linden) wrote:
> Hi all,
>
> Gee! This is quite a thread! Thanks for all the suggestions, ideas
> and passion. As always, this community shows it's full of talented
> (and opiniated) people :)
>
As usual :)
However, thanks fo
Attached is the basics of what is needed to get the gesture tracker to
listen to a port and react. For now, I've left out the XML server socket
bits and just cut it down to minimal code. The XML server socket works,
I just don't want to confuse that with the request to simply read a UDP
socket
Hi all,
Gee! This is quite a thread! Thanks for all the suggestions, ideas and
passion. As always, this community shows it's full of talented (and
opiniated) people :)
Since I'll be the guy tagged with driving/mentoring the intern on this
project on a day to day basis, I'm taking on summari
UDP is a bit more low level and asynchronous than TCP. Buffer overruns
would immediately mean drop packets, so a slow process wouldn't have to
worry about it being the reason the rest of the system is slow due,
like, TCP where blocked I/O could lead to other processes being blocked
until the on
In this case, you'll find that the functional difference between the two
is negligible. If you were going off of the metal to another machine,
that would be a bit different. For local use? UDP doesn't have an edge
in this particular circumstance.
Philip Rosedale wrote:
Looks like DBus is TCP
Most of that information is transport specific. I think I would prefer
the system stream based interface, so that unit tests can be easily
developed with predefined packets, and we could then test for correct
results even in a purely automated fashion of highly portable
regression tests.
I thi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Philip Rosedale wrote:
> Looks like DBus is TCP based - that still seems unneeded, I think we
> should use UDP, what think?
UDP could work, however I do prefer a standard protocol over yet another
homegrown one. TCP is not a big issue in this case -
Just to get this started for a proof-of-concept, my I suggest whatever
local system stream based format is available.
Philip Rosedale wrote:
> Looks like DBus is TCP based - that still seems unneeded, I think we
> should use UDP, what think?
>
> Jan Ciger wrote:
>> XML is definitely an overkill
Jan Ciger wrote:
> XML is useful for data definition,
The first two characters of the XML format, " in those two orders as a 16 bit value.
** If the either of those tests are true, then the data format is
defined as UTF8 for further communication.
* If either test false, then then the 16 bit val
Looks like DBus is TCP based - that still seems unneeded, I think we
should use UDP, what think?
Jan Ciger wrote:
> XML is definitely an overkill and certainly shouldn't be used for
> anything that has aspirations to be lightweight.
>
> Just use DBus - that is pretty standard and portable lightw
I think JSON, http://json.org is the leading standard name/value format.
Philip Rosedale wrote:
> do we need to use any sort of XML intepreter? My preference would be
> simple UDP with the contents being a name/value pair:
>
> gesture/nod
> lookatPoint/100,100,100
>
> etc. Seems important th
Jan Ciger wrote:
> Philip Rosedale wrote:
>
>> do we need to use any sort of XML intepreter? My preference would
>> be simple UDP with the contents being a name/value pair:
>>
>> gesture/nod lookatPoint/100,100,100
>>
>> etc. Seems important that this be extremely lightweight and fast.
>> I'm
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dzonatas Sol wrote:
> I haven't ruled out the possibility of a faster interface than XML.
> The approach I try to take it to make it work correctly and later
> make it fast.
Dzonatas, I think you should read these:
http://c2.com/cgi/wiki?XmlAbuse
ht
Pretty much as how it was noted earlier that LL gestures and human
gesture are distinct from each other, so is Dbus and XML quite distinct
from each other.
I haven't ruled out Dbus, either.
Jan Ciger wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Philip Rosedale wrote:
do
I haven't ruled out the possibility of a faster interface than XML. The
approach I try to take it to make it work correctly and later make it
fast. Given the portability issues just to initiate communication
between two separate processes, that part can certainly be done in XML.
The communicati
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Philip Rosedale wrote:
> do we need to use any sort of XML intepreter? My preference would
> be simple UDP with the contents being a name/value pair:
>
> gesture/nod lookatPoint/100,100,100
>
> etc. Seems important that this be extremely lightweig
do we need to use any sort of XML intepreter? My preference would be
simple UDP with the contents being a name/value pair:
gesture/nod
lookatPoint/100,100,100
etc. Seems important that this be extremely lightweight and fast. I'm
a bit out of the loop, development wise, so maybe i'm wrong.
Without much eyeballs on the code yet, it appears
newview/llvoiceclient.h/cpp can be pretty much shallow copied and used
to get a head start on this.
* Personally, I would do this copy and replace the vivox specific IO
with the standard XML interpreter (if not already done).
* Even if llgesture
30 matches
Mail list logo
