On 9/19/06, John Hurliman <[EMAIL PROTECTED]> wrote:
Austin Jennings wrote:
> On 2006/09/19, at 19:27, Adam Frisby wrote:
>
>> Three problems I can see -
>>
>> 1. If keywords.txt changes ordering - everything gets busted
>> 2. If LL makes a change to a packet, it's guarunteed broken now.
>> (such as
>> if LL removes a field - a non-breaking change right now)
>> 3. We need to release new DLL's for each update, versus new protocol and
>> keyword files.
Removing a field from the protocol and not replacing it with another is
a fairly rare change, but yes it would be a case where things would
break with pre-generation but not the hashtable method (although the
client app will still be trying to set the field and possibly depend on
it doing something, so you get undefined behavior). More common
scenarios would break any method we can come up with, as a change in how
things are done means the client needs to do things differently. A new
field is added that is required to be non-zero, a field or block is
moved or renamed, or the keywords ordering changes (requires a
keywords.txt now, and a new libsecondlife.dll in the future). We will
need an update system in place though, which entails an automated build
system on the server as well. Fortunately this is very easy with nant.
_______________________________________________
libsecondlife-dev mailing list
libsecondlife-dev@gna.org
https://mail.gna.org/listinfo/libsecondlife-dev
http://www.libsecondlife.org/
--
Tom Wilson
[EMAIL PROTECTED]
KI6ABZ
_______________________________________________ libsecondlife-dev mailing list libsecondlife-dev@gna.org https://mail.gna.org/listinfo/libsecondlife-dev http://www.libsecondlife.org/
