I see another problem with this as well: VS wouldn't know what all the packets were, so adding/deleting would require a manual solution file change.
On 10/28/06, John Hurliman <[EMAIL PROTECTED]> wrote:
Ryan Gahl wrote: > Hello all. I understand busy is busy... but I have a huge request, > something that would vastly enable people to more quickly grok working > with the various packet classes... > > Please, let's consider chaning the autogeneration process to break out > the huge __Packets__.cs file into 1 file per class in a folder called > "Packets"... This is theoretically not a very hard change to make, and > I'm sure I'll end up doing it on my own and maintaining my local copy > that way if the team doesn't agree this is a good idea... but overall > the community here would benefit because it's not currently possible > to leisurely scroll down that file to browse all the available classes > and their members, it's just too big. > > John, please give this some thought. I think it would really speed > things along. Thanks. > There is no useful information to be gleaned from the _Packets_.cs file, it's just a bunch of constructors and serialization/deserialization functions. If you are looking for protocol documentation, the only resource we have at the moment is the message_template.msg file (which still has some Linden comments as well), and eventually we may look at a way of writing xml documentation for each packet that can be fed in to mapgenerator and eventually output with the rest of the ndoc generated html. I'm not ruling it out as a possibility, just a heads up that the _Packets_ file is the wrong place to be looking for documentation. An upside of breaking it out in to 500+ separate files is it would be easier to see what packets have changed by looking through svn logs, a downside would be the overhead on the compiler of handling all those separate files. If you do modify mapgenerator to output separate files, submit the patch to the gna.org page and we can look at some benchmarks with VS2005, NAnt, and Mono to see what the impact is. John _______________________________________________ libsecondlife-dev mailing list libsecondlife-dev@gna.org https://mail.gna.org/listinfo/libsecondlife-dev http://www.libsecondlife.org/
-- --Jesse _______________________________________________ libsecondlife-dev mailing list libsecondlife-dev@gna.org https://mail.gna.org/listinfo/libsecondlife-dev http://www.libsecondlife.org/
