Btw, awesome work by all so far. This will prove important to many people.
On 10/28/06,
Jesse Nesbitt <[EMAIL PROTECTED]> wrote:
On 10/28/06, Ryan Gahl <[EMAIL PROTECTED]> wrote:
> Couple of points here... first of all, how many packet classes are there
> really? 500+?? While that seems like a lot of files (actually it is quite a
> lot)... this is a common practice for things like a data access layer (1
> file/class per database table) in a multi-tiered architecture. It's
> certainly more manageable than a 100,000+ line file. The size of this file
> also makes me wonder how much code rundancy exists ( i.e., could we use a
> base class or otherwise factor out a lot of common code?). The second
> point... about adding to the compiler overhead. That would not be the case.
> The compilation would take the same amount of time. You use the same
> namespace in each file, and the compiler is optimized to not actually try
> loading overlapping dependencies 500+ times. That's a great advantage to
> .NET vs. the old COM model...
Well, LL has diffrent blocks with the same name, so most of that
redundancy is needed.
Still, one file per packet is really messy for people. The point of
_Packets_.cs is so that people DON'T see it, it's automaticly
generated.
> Now, the point about there being no information to glean from the packets
> classes... I'm just going from assumptions I guess, but when I looked at the
> AnimationSample project, I noticed that the animation packet class had
> public properties on it such as "AnimID", etc. that were specific to that
> packet, and represented important data items to send down the stream to
> achieve the desired action. It just so happens that's exactly the type of
> stuff I want to know (what are the public properties and methods unique for
> the certain packet classes I'm interested in using, and moreover... what ARE
> all of the interesting packet classes I can choose from?)... So my
> assumption is that yes, there is valuable information in the __Packets__.cs
> file.
Nothing that can't be gleaned quicker or easier from message_template.msg
It has types and comments and everything
> And yes, I use the MS C# VS Express (while I'm in the office as my company
> owns no full VS licenses), and the full VS.NET 2005 at home as I still have
> my copy from my last employer where I was given and MSDN Universal
> subscription... Not exactly sure why an assumption was made that I wasn't
> using either (1 of the respondants made the suggestion that I should use VS
> Express). Was the thought there, that by using Intellisense I'd be able to
> browse all the classes and therefore the public members?
Yeah, that's the thought., and the message template file is there too.
Other tools can do introspection into CIL assemblies as well.
> Anyway... I'm not really trying to place this under heavy debate out
> anything, especiall since I'm new to the community.. just think there is
> value in it. Maybe that will be my first contribution. We'll see how
> allowing time is though :-)
>
>
>
>
> On 10/27/06, Jesse Nesbitt <[EMAIL PROTECTED]> wrote:
> > 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/
> >
>
>
>
> --
> Ryan Gahl
> Application Development Consultant
> Athena Group, Inc.
> Inquire: 1-920-955-1457
> Blog: http://www.someElement.com
> _______________________________________________
> 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/
--
Ryan Gahl
Application Development Consultant
Athena Group, Inc.
Inquire: 1-920-955-1457
Blog: http://www.someElement.com
_______________________________________________ libsecondlife-dev mailing list libsecondlife-dev@gna.org https://mail.gna.org/listinfo/libsecondlife-dev http://www.libsecondlife.org/
