Duh.
>The other side of this is an optional update server that
>produces the latest stable libsecondlife.dll (updated after every
>message_template.msg update) for client apps to take advantage of. The
>details can be hashed out some more in a separate thread since this is a
>big change.
>produces the latest stable libsecondlife.dll (updated after every
>message_template.msg update) for client apps to take advantage of. The
>details can be hashed out some more in a separate thread since this is a
>big change.
I guess I should have read that before I send that last reply. Feel free to ignore. ;-)
On 9/19/06, Tom Wilson <[EMAIL PROTECTED]> wrote:
John, do you think that having a client updater (for the DLL and protocol files) is also an appropriate goal for 1.0? Just a thought.
On 9/19/06, John Hurliman <[EMAIL PROTECTED] > wrote:Static Sprocket wrote:
>> > * A stabilized API for the "bottom end" of the library, the low level
>> > packet handling and networking
>
>> I wasn't aware that the API for low level networking was unstable.
>>
>
> I believe it isn't unstable, in that it doesn't work -- but rather
> unstable in that there are still (relatively) frequent changes done to
> it. Like the recent adding of the disconnect events, and varies parts
> of the networking code have been refactored multiple times.
>
> So what I'm hoping John is saying, is that we'll set some of the API
> in stone so it's not a moving target to develop against.
>
> --
> Static
With the most recent update it should be fairly durable, and once I get
to the malformed packet and high load testing harnesses we should have
something rock solid. Static is correct though, what I'm talking about
is freezing the outward facing API in NetworkManager.cs. It would be
naive to think we could define a full API for everything you might want
to do in SL at this point and time and not change it, but the networking
layer seems stable enough, and this would allow client apps some
certainty that the callback interface isn't going to change, devs that
are working on the upper layer some assurance that their code will work
tomorrow, etc.
On the regression testing, the nunit setup in libsl will take a little
bit to get everything working how we want, but the basic framework is
already in svn; a minimal server that is libsl-enabled and exposes
function calls to the client. The difficult part will be figuring out
how to write tests properly since both the client and server objects in
the framework are using libsl, so for example an endian issue could be
handled wrong on both sides and interpreted as a success. Minor issues
though, we just need to be aware of them when writing tests.
The code generation is actual a lot closer to reality now, axial has
been doing a fair bit of work on it. By pre-generating all the code it
should remove the need for the external
keywords.txt/message_template.msg to be shipped with applications, and
it produces code optimized for each packet (without the overhead of
reflection). The other side of this is an optional update server that
produces the latest stable libsecondlife.dll (updated after every
message_template.msg update) for client apps to take advantage of. The
details can be hashed out some more in a separate thread since this is a
big change.
Terrain awareness essentially means parsing LayerData and most likely
providing a bitmap heightfield in the Region class. A Linden offered
support on providing the movement information so we've been working on
other things. And "Includes SLProxy" is a bit misleading since that was
written before we dropped the whole official release thing. I think it
would be a good idea to still use versioning, but if we migrate to this
idea where a new libsecondlife.dll is generated every week or two weeks
we can't continually be announcing new releases. Finally, the camera
movement is "sort of" implemented in that it sends a single packet
saying we're looking directly east (or maybe north I don't recall). The
roadmap goal means adding a function where clients can set a new camera
position, and most likely helper functions for some of the quaternion
details involved in creating a camera angle.
John
_______________________________________________
libsecondlife-dev mailing list
libsecondlife-dev@gna.org
https://mail.gna.org/listinfo/libsecondlife-dev
http://www.libsecondlife.org/
--
Tom Wilson
[EMAIL PROTECTED]
KI6ABZ
--
Tom Wilson
[EMAIL PROTECTED]
KI6ABZ
_______________________________________________ libsecondlife-dev mailing list libsecondlife-dev@gna.org https://mail.gna.org/listinfo/libsecondlife-dev http://www.libsecondlife.org/
