xsrcg-devel — Discussion related to the development of XSRCG

Re: [xsrcg-devel] Licencing

[Max N. <max...@fr...>]

Le 17 juin 2004, =E0 05:35, Adam Brown a =E9crit :

> A subject I have kind of been dreading to bring up, since it can push=20=

> a lot of sensitive buttons in people, but it's something we'll need to=20=

> address soon. Do you guys have any preferences or any particular=20
> licenses you dislike? I'll just come right out and say that I'm=20
> partial to the BSD license. My history with FreeBSD and such has sort=20=

> of brought me up under the BSD paradigm throughout my computing=20
> career. I think there are better licenses than the GPL, which I'd like=20=

> to avoid. If anyone is dead set on a GPL-style license though, I'd=20
> consider the LGPL.
>
> If you're familiar with any other licenses or are partial to any one=20=

> way or another, now is probably the time to get it worked out. :-)

	Well... I'm in favor of either the GPL, or the BSD license. =
Although=20
the one thing that creeps me out with BSD is that unless I'm mistaken,=20=

anyone is allowed to take our program, claim it as their own and sell=20
it as long as we're credited in the source code (which then no one will=20=

see), right?
	Not that I do expect anyone to do that, but you never know... =
So, I'm=20
neutral on this one.

-- Max
maxnoel_fr at yahoo dot fr -- ICQ #85274019
"Look at you hacker... A pathetic creature of meat and bone, panting=20
and sweating as you run through my corridors... How can you challenge a=20=

perfect, immortal machine?"

Re: [xsrcg-devel] Program Design Updates

[Max N. <max...@ya...>]

Le 16 juin 2004, =E0 08:55, Adam Brown a =E9crit :

> Okay, Jesse and I had a pretty long talk this evening on IRC.=20
> Hopefully we can all three get together there soon. Max, you might let=20=

> us know what time is good for you locally, since you're the odd one=20
> out, and hopefully Jesse and I can try and be around at that=20
> time...just a thought.

	I'm usually awake from 08:00 to about midnight GMT. I'm not =
always=20
online during that time, but if you want me to be I'll try.

(by the way, sorry for the apparent lag in my replies, but Yahoo Mail=20
seems to be having problems -- it took my last mail about 24 hours to=20
get to the list then back to me)

> On to the business portion now. We talked about a lot of stuff and=20
> eventually got into some good ideas on how to approach the program=20
> design. Both from a cross-platform standpoint and from a general=20
> design standpoint. We seem to agree that the best way to do this would=20=

> be to break away all of the back-end work into a separate library.=20
> There are several key advantages that'll get into below and neither of=20=

> us see any real drawbacks to this design.

	Agreed.

> First, speed. By breaking the guts of the program into a self=20
> contained library we can write it in pure C and do it with a minimal=20=

> of fuss. This will give the workhorse part of the program a good boost=20=

> in speed and efficiency.

	I'm not sure about that. Objective-C (or at the very least C++ =
--=20
something object-oriented) seemed far more suited to the job to me. The=20=

most computationally intensive calculations I can think of in the=20
Shadowrun system can be run on a Casio programable calculator without=20
noticeable lag, so I don't think speed will be a problem in the=20
back-end. Besides, from what I've read ObjC is as fast as C, except=20
that method calls take roughly 1.5* more time.

> Second, portability. This seems kind of obvious. The library would be=20=

> written in C and could be compiled under multiple platforms. We or=20
> other people could then take the library and write an interface (GUI=20=

> or not even) on top of the library to perform tasks in other=20
> environments and other operating systems. This will lend well to an=20
> OSX/Unix/Windows hybrid. The OS X stuff will be able to stay Cocoa and=20=

> will be native, while the other operating system would benefit from=20
> being able to have native support as well. Obviously Windows support=20=

> isn't really a prime focus, but if it becomes an issue this approach=20=

> will make it easy to address. In addition, other platforms such as=20
> Palm and other handhelds could conceivably take advantage of the=20
> library.

	Same as above. Actually, the reason why I'd have liked to use =
ObjC is=20
everything in the NS API that's not GUI-related. There are a number of=20=

classes (NSMutableDictionary, for example -- associative array that can=20=

be grown/shrunk at will) that would be extremely helpful, and GNUStep=20
is available for a lot of platforms.
	I see your point, though, when it comes to handhelds. GNUStep is=20=

unavailable for those, and even if it were the processors in these=20
machines are quite underpowered. But then C++ would be the way to go=20
IMO. I fail see the point in not using an object-oriented language in a=20=

project that screams "OOP" as much as this one does.

> Third, it will aid development of our primary applications. By=20
> breaking away the library we can work on the library code separate=20
> from the GUI code. Thus development of one won't be sacrificed to=20
> development of the other. We can have a bare bones skeleton of the=20
> library in place quickly for the GUI to interface with while it's=20
> developed and the library could use simple text based checks while=20
> it's being worked on. Also, once the code of one part is in place, it=20=

> won't be as reliant on the other.

	Model-View-Controller. Amen to that.

> Fourth, flexibility. By breaking the workhorse code away into a=20
> library it gives us a huge amount of flexibility as to what we want to=20=

> do with the code once our basic goals are met. Some ideas were=20
> presented in the portability section, but conceivably we could do=20
> quite a bit with it, as well as allowing other people to build upon=20
> the library for their own needs, if they want to pursue something we=20=

> don't have the time, resources, or inclination to pursue. Which could=20=

> include a Windows program or any number of things.

	Yup.

> Fifth, expandability. Once the basic library is set, which will=20
> include the basics of handling a character and such we'll be able to=20=

> expand on that. However, we won't have to add it in the same library=20=

> or in the same piece of code. We can avoid unnecessary bloat by adding=20=

> further features into additional libraries. Things such as Cyberdeck=20=

> creation, gun creation, spell creation, vehicle creation, etc. can all=20=

> be added on an as needed basis into any program by keeping things in=20=

> seperate self-contained libraries.

	Good idea.

> It's late, and it's time for me to get some sleep.
>
> Nighto!

	Have a good rest!

-- Max
maxnoel_fr at yahoo dot fr -- ICQ #85274019
"Look at you hacker... A pathetic creature of meat and bone, panting=20
and sweating as you run through my corridors... How can you challenge a=20=

perfect, immortal machine?"

[xsrcg-devel] Database Possibilities

[Adam B. <co...@di...>]

I've also been looking into possible database libraries to use for our 
back-end storage purposes. Overall it seems like SQLite, 
http://www.sqlite.org, might be the way to go. The developer's have 
placed SQLite in the public domain so we don't have to worry about 
license compatibility. Also, the fine folks at Blackhole have a Cocoa 
wrapper that's BSD licensed, so yet again we don't have to worry about 
compatibility issues there. The stuff can be downloaded at the 
following url and includes an example project. 
http://www.blackholemedia.com/code/.

And so it goes, finding our building blocks.

--
Adam Brown
co...@di...

[xsrcg-devel] Licencing

[Adam B. <co...@di...>]

A subject I have kind of been dreading to bring up, since it can push a 
lot of sensitive buttons in people, but it's something we'll need to 
address soon. Do you guys have any preferences or any particular 
licenses you dislike? I'll just come right out and say that I'm partial 
to the BSD license. My history with FreeBSD and such has sort of 
brought me up under the BSD paradigm throughout my computing career. I 
think there are better licenses than the GPL, which I'd like to avoid. 
If anyone is dead set on a GPL-style license though, I'd consider the 
LGPL.

If you're familiar with any other licenses or are partial to any one 
way or another, now is probably the time to get it worked out. :-)

--
Adam Brown
co...@di...

[xsrcg-devel] How Cross-Platform?

[Adam B. <co...@di...>]

I think this topic on it's own devserves it's own thread.

We've pretty much decided to do a library to power the program, so the 
next step is to figure out how to write the library. I guess the 
question comes down to this; do we really care that much about future 
support on Windows and non-Cocoa/GNUStep environments?

Yes, it would be nice to have a library compatible across platforms, 
but do we want that to become part of the scope of this project, or do 
we want to stick with the original idea of Cocoa/GNUStep support?

Personally, while I feel that having the library be compatible across 
any number of platforms, it's not something I'm willing to bend over 
backwards for if we all feel it'll be to the detriment of the original 
Cocoa/GNUStep environment. I feel Cocoa/GNUStep should certainly take 
precedence here.

Perhaps a fully cross-platform library, based off of our Cocoa/GNUStep 
work could be the focus of a future project. Even if we go all out into 
Coca/GNUStep-land porting the library could probably be done and might 
be preferable to making concessions to our preferred target.

--
Adam Brown
co...@di...

Re: [xsrcg-devel] Program Design Updates

[Jesse W. <jwa...@sp...>]

/* Thus spake Adam Brown (co...@di...) on  0 */

> 
> Quoting Max Noel <max...@fr...>:
> 
> > 	Sorry if you get this message 2 times, but it seems that Yahoo Mail
> > 
> > has decided to get a Guinness Book entry for "slowest e-mail
> > delivery". 
> > I originally sent this this morning and it still hasn't arrived. So,
> > 
> > here I go again, from a different e-mail account...
> > 
> 
> Not a problem at all. I'm using my webmail app this time around and it
> might not wrap stuff as pretty as Mail.app.
> 
> > 
> > Le 16 juin 2004, ? 08:55, Adam Brown a ?crit :
> > 
> > > Okay, Jesse and I had a pretty long talk this evening on IRC. 
> > > Hopefully we can all three get together there soon. Max, you might
> > let 
> > > us know what time is good for you locally, since you're the odd one
> > 
> > > out, and hopefully Jesse and I can try and be around at that 
> > > time...just a thought.
> > 
> > 	I'm usually awake from 08:00 to about midnight GMT. I'm not always 
> > online during that time, but if you want me to be I'll try.
> > 
> 
> Well, you don't need to try to be online all the time. Mostly it's just
> a "when is it possible to catch Max" question.
> 
> > 
> > > First, speed. By breaking the guts of the program into a self 
> > > contained library we can write it in pure C and do it with a
> > minimal 
> > > of fuss. This will give the workhorse part of the program a good
> > boost 
> > > in speed and efficiency.
> > 
> > 	I'm not sure about that. Objective-C (or at the very least C++ 
> > -- something object-oriented) seemed far more suited to the job to
> me.
> > The 
> > most computationally intensive calculations I can think of in the 
> > Shadowrun system can be run on a Casio programable calculator without
> > 
> > noticeable lag, so I don't think speed will be a problem in the 
> > back-end. Besides, from what I've read ObjC is as fast as C, except 
> > that method calls take roughly 1.5* more time.
> > 
> 
> Point taken. C vs C++ vs ObjC in this intance probably wouldn't make
> much difference speed-wise. Although I think portability of the library
> is important, and it's tough to find ObjC compilers on some platforms.
> 

of course.  using C would be more a matter of portablility than of
speed.  though, speed could certainly influence certain levels of
portability.  more on this below.
 
> 
> > > Second, portability. This seems kind of obvious. The library would
> > be 
> > > written in C and could be compiled under multiple platforms. We or
> > 
> > > other people could then take the library and write an interface
> > (GUI 
> > > or not even) on top of the library to perform tasks in other 
> > > environments and other operating systems. This will lend well to an
> > 
> > > OSX/Unix/Windows hybrid. The OS X stuff will be able to stay Cocoa
> > and 
> > > will be native, while the other operating system would benefit from
> > 
> > > being able to have native support as well. Obviously Windows
> > support 
> > > isn't really a prime focus, but if it becomes an issue this
> > approach 
> > > will make it easy to address. In addition, other platforms such as
> > 
> > > Palm and other handhelds could conceivably take advantage of the 
> > > library.
> > 
> > 	Same as above. Actually, the reason why I'd have liked to use ObjC
> > is 
> > everything in the NS API that's not GUI-related. There are a number
> > of 
> > classes (NSMutableDictionary, for example -- associative array that
> > can 
> > be grown/shrunk at will) that would be extremely helpful, and GNUStep
> > 
> > is available for a lot of platforms.
> > 	I see your point, though, when it comes to handhelds. GNUStep is 
> > unavailable for those, and even if it were the processors in these 
> > machines are quite underpowered. But then C++ would be the way to go
> >
> 
Max, yes i had the same ideas about ObjC.  i love the non-gui lib 
that's in there.  all the NS stuff.  it's good stuff.  we even talked
about using objective C for the back lib.  but again, much of it is a
matter of portability.  if we *did* decide to use C, i would at least 
want to use glib or something.  glib, and others, provide some
great functions and defs.  i.e. linked lists, mutable strings,
mutable lists, hashing.  it's something we need to consider.  not
just because C would be more difficult, but because of what other
langs offer.  which happens to be really good standard libs that
contain stuff that we wouldn't want to recode.  i will say that
even C++ can get ugly accross platforms and stdlib implementations.

> We'll have to look at that. Obviously if we use C or something in the
> library the library won't be able to take advantage of some of the ObjC
> stuff, but at the same time, the library functions and storage could be
> loaded into an ObjC wrapper under Cocoa/GNUStep to give us that
> flexibility and power on those platforms. 
> 
> I mean, I can see how NSMutableDictionary could be very handy for
> storing just about everything short of attributes. So that's a pretty
> valid argument. We'll definitely need to look into how having a
> non-ObjC library will affect things like that, or if we can work around
> them easily enough to keep the library as portable as possible.
>  
> > IMO. I fail see the point in not using an object-oriented language in
> > a 
> > project that screams "OOP" as much as this one does.
> > 
> 
> Very true. Another point we need to look at that I didn't really
> address.
> 
> I'll leave it at that for now and get back to work...heh.

OOP is great, i agree.  the main things we would be taking advantage
of in this project are polymorphism and inheritance.  stuff like gear
with mostly the same attributes and stuff like the different
generation systems would be tougher in C...of course there we would
use a procedural approach instead of trying to force it into an
Object-Oriented model.  but, still, OOP would be much more
programmer-friendly for this project.  however, as we've
discussed--objc wouldn't be as portable.  So, we may need to be
discussing our scope and goals before what language we need to use.
exactly how portable do we want this lib to be?  perhaps the answer
truly is a middle-ground between portability and programmability.  in
that case, the best middle-ground candidate just may be C++ (without
a lot of fanciness).  i dunno.  but right here and right now, i'm not
an advocate for anything but this project =).  so don't think that
i'm pushing anything.  i'm up for whatever.  if we *do* decide to use
straight C, then i would definitely want to investigate glib's
portability.  let me link you guy's to info about glib so you know
what i mean: 
http://www.gtk.org/tutorial/ch-glib.html
http://developer.gnome.org/doc/API/glib/
i'm not saying we'd have to use glib, but a similar library would be
very nice if we code in straight C.

Max, i'm not sure if adam mentioned libxml2 or not.  i was playing
with it last night, and it's quite nice.  we could use that for xml
handling in any language that we decide to write the lib.

gotta go.  take care.

-jesse
jwa...@sp...

> 
> --
> Adam Brown
> co...@di...
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
> Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
> Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
> REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
> _______________________________________________
> xsrcg-devel mailing list
> xsr...@li...
> https://lists.sourceforge.net/lists/listinfo/xsrcg-devel
> 
> 
/* End of Adam Brown's message */

Re: [xsrcg-devel] Program Design Updates

[Adam B. <co...@di...>]

Quoting Max Noel <max...@fr...>:

> 	Sorry if you get this message 2 times, but it seems that Yahoo Mail
> 
> has decided to get a Guinness Book entry for "slowest e-mail
> delivery". 
> I originally sent this this morning and it still hasn't arrived. So,
> 
> here I go again, from a different e-mail account...
> 

Not a problem at all. I'm using my webmail app this time around and it
might not wrap stuff as pretty as Mail.app.

> 
> Le 16 juin 2004, à 08:55, Adam Brown a écrit :
> 
> > Okay, Jesse and I had a pretty long talk this evening on IRC. 
> > Hopefully we can all three get together there soon. Max, you might
> let 
> > us know what time is good for you locally, since you're the odd one
> 
> > out, and hopefully Jesse and I can try and be around at that 
> > time...just a thought.
> 
> 	I'm usually awake from 08:00 to about midnight GMT. I'm not always 
> online during that time, but if you want me to be I'll try.
> 

Well, you don't need to try to be online all the time. Mostly it's just
a "when is it possible to catch Max" question.

> 
> > First, speed. By breaking the guts of the program into a self 
> > contained library we can write it in pure C and do it with a
> minimal 
> > of fuss. This will give the workhorse part of the program a good
> boost 
> > in speed and efficiency.
> 
> 	I'm not sure about that. Objective-C (or at the very least C++ 
> -- something object-oriented) seemed far more suited to the job to
me.
> The 
> most computationally intensive calculations I can think of in the 
> Shadowrun system can be run on a Casio programable calculator without
> 
> noticeable lag, so I don't think speed will be a problem in the 
> back-end. Besides, from what I've read ObjC is as fast as C, except 
> that method calls take roughly 1.5* more time.
> 

Point taken. C vs C++ vs ObjC in this intance probably wouldn't make
much difference speed-wise. Although I think portability of the library
is important, and it's tough to find ObjC compilers on some platforms.



> > Second, portability. This seems kind of obvious. The library would
> be 
> > written in C and could be compiled under multiple platforms. We or
> 
> > other people could then take the library and write an interface
> (GUI 
> > or not even) on top of the library to perform tasks in other 
> > environments and other operating systems. This will lend well to an
> 
> > OSX/Unix/Windows hybrid. The OS X stuff will be able to stay Cocoa
> and 
> > will be native, while the other operating system would benefit from
> 
> > being able to have native support as well. Obviously Windows
> support 
> > isn't really a prime focus, but if it becomes an issue this
> approach 
> > will make it easy to address. In addition, other platforms such as
> 
> > Palm and other handhelds could conceivably take advantage of the 
> > library.
> 
> 	Same as above. Actually, the reason why I'd have liked to use ObjC
> is 
> everything in the NS API that's not GUI-related. There are a number
> of 
> classes (NSMutableDictionary, for example -- associative array that
> can 
> be grown/shrunk at will) that would be extremely helpful, and GNUStep
> 
> is available for a lot of platforms.
> 	I see your point, though, when it comes to handhelds. GNUStep is 
> unavailable for those, and even if it were the processors in these 
> machines are quite underpowered. But then C++ would be the way to go
>

We'll have to look at that. Obviously if we use C or something in the
library the library won't be able to take advantage of some of the ObjC
stuff, but at the same time, the library functions and storage could be
loaded into an ObjC wrapper under Cocoa/GNUStep to give us that
flexibility and power on those platforms. 

I mean, I can see how NSMutableDictionary could be very handy for
storing just about everything short of attributes. So that's a pretty
valid argument. We'll definitely need to look into how having a
non-ObjC library will affect things like that, or if we can work around
them easily enough to keep the library as portable as possible.
 
> IMO. I fail see the point in not using an object-oriented language in
> a 
> project that screams "OOP" as much as this one does.
> 

Very true. Another point we need to look at that I didn't really
address.

I'll leave it at that for now and get back to work...heh.

--
Adam Brown
co...@di...

Re: [xsrcg-devel] Program Design Updates

[Max N. <max...@fr...>]

	Sorry if you get this message 2 times, but it seems that Yahoo =
Mail=20
has decided to get a Guinness Book entry for "slowest e-mail delivery".=20=

I originally sent this this morning and it still hasn't arrived. So,=20
here I go again, from a different e-mail account...


Le 16 juin 2004, =E0 08:55, Adam Brown a =E9crit :

> Okay, Jesse and I had a pretty long talk this evening on IRC.=20
> Hopefully we can all three get together there soon. Max, you might let=20=

> us know what time is good for you locally, since you're the odd one=20
> out, and hopefully Jesse and I can try and be around at that=20
> time...just a thought.

	I'm usually awake from 08:00 to about midnight GMT. I'm not =
always=20
online during that time, but if you want me to be I'll try.

(by the way, sorry for the apparent lag in my replies, but Yahoo Mail=20
seems to be having problems -- it took my last mail about 24 hours to=20
get to the list then back to me)

> On to the business portion now. We talked about a lot of stuff and=20
> eventually got into some good ideas on how to approach the program=20
> design. Both from a cross-platform standpoint and from a general=20
> design standpoint. We seem to agree that the best way to do this would=20=

> be to break away all of the back-end work into a separate library.=20
> There are several key advantages that'll get into below and neither of=20=

> us see any real drawbacks to this design.

	Agreed.

> First, speed. By breaking the guts of the program into a self=20
> contained library we can write it in pure C and do it with a minimal=20=

> of fuss. This will give the workhorse part of the program a good boost=20=

> in speed and efficiency.

	I'm not sure about that. Objective-C (or at the very least C++ =
--=20
something object-oriented) seemed far more suited to the job to me. The=20=

most computationally intensive calculations I can think of in the=20
Shadowrun system can be run on a Casio programable calculator without=20
noticeable lag, so I don't think speed will be a problem in the=20
back-end. Besides, from what I've read ObjC is as fast as C, except=20
that method calls take roughly 1.5* more time.

> Second, portability. This seems kind of obvious. The library would be=20=

> written in C and could be compiled under multiple platforms. We or=20
> other people could then take the library and write an interface (GUI=20=

> or not even) on top of the library to perform tasks in other=20
> environments and other operating systems. This will lend well to an=20
> OSX/Unix/Windows hybrid. The OS X stuff will be able to stay Cocoa and=20=

> will be native, while the other operating system would benefit from=20
> being able to have native support as well. Obviously Windows support=20=

> isn't really a prime focus, but if it becomes an issue this approach=20=

> will make it easy to address. In addition, other platforms such as=20
> Palm and other handhelds could conceivably take advantage of the=20
> library.

	Same as above. Actually, the reason why I'd have liked to use =
ObjC is=20
everything in the NS API that's not GUI-related. There are a number of=20=

classes (NSMutableDictionary, for example -- associative array that can=20=

be grown/shrunk at will) that would be extremely helpful, and GNUStep=20
is available for a lot of platforms.
	I see your point, though, when it comes to handhelds. GNUStep is=20=

unavailable for those, and even if it were the processors in these=20
machines are quite underpowered. But then C++ would be the way to go=20
IMO. I fail see the point in not using an object-oriented language in a=20=

project that screams "OOP" as much as this one does.

> Third, it will aid development of our primary applications. By=20
> breaking away the library we can work on the library code separate=20
> from the GUI code. Thus development of one won't be sacrificed to=20
> development of the other. We can have a bare bones skeleton of the=20
> library in place quickly for the GUI to interface with while it's=20
> developed and the library could use simple text based checks while=20
> it's being worked on. Also, once the code of one part is in place, it=20=

> won't be as reliant on the other.

	Model-View-Controller. Amen to that.

> Fourth, flexibility. By breaking the workhorse code away into a=20
> library it gives us a huge amount of flexibility as to what we want to=20=

> do with the code once our basic goals are met. Some ideas were=20
> presented in the portability section, but conceivably we could do=20
> quite a bit with it, as well as allowing other people to build upon=20
> the library for their own needs, if they want to pursue something we=20=

> don't have the time, resources, or inclination to pursue. Which could=20=

> include a Windows program or any number of things.

	Yup.

> Fifth, expandability. Once the basic library is set, which will=20
> include the basics of handling a character and such we'll be able to=20=

> expand on that. However, we won't have to add it in the same library=20=

> or in the same piece of code. We can avoid unnecessary bloat by adding=20=

> further features into additional libraries. Things such as Cyberdeck=20=

> creation, gun creation, spell creation, vehicle creation, etc. can all=20=

> be added on an as needed basis into any program by keeping things in=20=

> seperate self-contained libraries.

	Good idea.

> It's late, and it's time for me to get some sleep.
>
> Nighto!

	Have a good rest!

-- Max
maxnoel_fr at yahoo dot fr -- ICQ #85274019
"Look at you hacker... A pathetic creature of meat and bone, panting=20
and sweating as you run through my corridors... How can you challenge a=20=

perfect, immortal machine?"=

[xsrcg-devel] Program Design Updates

[Adam B. <co...@di...>]

Okay, Jesse and I had a pretty long talk this evening on IRC. Hopefully 
we can all three get together there soon. Max, you might let us know 
what time is good for you locally, since you're the odd one out, and 
hopefully Jesse and I can try and be around at that time...just a 
thought.

On to the business portion now. We talked about a lot of stuff and 
eventually got into some good ideas on how to approach the program 
design. Both from a cross-platform standpoint and from a general design 
standpoint. We seem to agree that the best way to do this would be to 
break away all of the back-end work into a separate library. There are 
several key advantages that'll get into below and neither of us see any 
real drawbacks to this design.

Now, it might seem overly long, but I'm listing this stuff for three 
reasons. First, to catch you up on where Jesse and I are in our 
thinking. Second, to sort of distill the conversation and have a 
reference for emails while we can't IRC. And third, to have a copy of 
these reasons listed for archival purposes.

First, speed. By breaking the guts of the program into a self contained 
library we can write it in pure C and do it with a minimal of fuss. 
This will give the workhorse part of the program a good boost in speed 
and efficiency.

Second, portability. This seems kind of obvious. The library would be 
written in C and could be compiled under multiple platforms. We or 
other people could then take the library and write an interface (GUI or 
not even) on top of the library to perform tasks in other environments 
and other operating systems. This will lend well to an OSX/Unix/Windows 
hybrid. The OS X stuff will be able to stay Cocoa and will be native, 
while the other operating system would benefit from being able to have 
native support as well. Obviously Windows support isn't really a prime 
focus, but if it becomes an issue this approach will make it easy to 
address. In addition, other platforms such as Palm and other handhelds 
could conceivably take advantage of the library.

Third, it will aid development of our primary applications. By breaking 
away the library we can work on the library code separate from the GUI 
code. Thus development of one won't be sacrificed to development of the 
other. We can have a bare bones skeleton of the library in place 
quickly for the GUI to interface with while it's developed and the 
library could use simple text based checks while it's being worked on. 
Also, once the code of one part is in place, it won't be as reliant on 
the other.

Fourth, flexibility. By breaking the workhorse code away into a library 
it gives us a huge amount of flexibility as to what we want to do with 
the code once our basic goals are met. Some ideas were presented in the 
portability section, but conceivably we could do quite a bit with it, 
as well as allowing other people to build upon the library for their 
own needs, if they want to pursue something we don't have the time, 
resources, or inclination to pursue. Which could include a Windows 
program or any number of things.

Fifth, expandability. Once the basic library is set, which will include 
the basics of handling a character and such we'll be able to expand on 
that. However, we won't have to add it in the same library or in the 
same piece of code. We can avoid unnecessary bloat by adding further 
features into additional libraries. Things such as Cyberdeck creation, 
gun creation, spell creation, vehicle creation, etc. can all be added 
on an as needed basis into any program by keeping things in seperate 
self-contained libraries.

Now, a lot of that seems to address issues that don't concern us at the 
present moment, but that's the final reason to be thinking about it 
this way. It gives us a program design that's flexible to just about 
any needs in the future.




Alrighty, there's a good list of basically the arguments we came down 
to for the use of this design. We can't really think of any drawbacks, 
so if there's anything that comes to mind with you  Max let us know. 
Also, if you want to address anything feel free to let us have it. :-)

Also, Jesse might feel free to add anything I left out, if I did.

It's late, and it's time for me to get some sleep.

Nighto!

--
Adam Brown
co...@di...

Re: [xsrcg-devel] objective-c, the project, design, updates

[Max N. <max...@ya...>]

Le 15 juin 2004, =E0 06:35, Jesse a =E9crit :

> alright.  three's a good number =3D).  i think so, anyway.  Max, how =
much
> experience do you have with objective-c/GNUstep/Cocoa?

	I'm currently learning Objective-C and Cocoa. As for GNUStep, =
well...=20
I've used WindowMaker but that's about all. I figured this project=20
would be a good occasion to learn more... So I guess that makes me a=20
newbie, right? But don't worry, I learn fast. ^^

> also, do you primarily use/develop linux or Mac OS X?  do you have =
both
> platforms available?  i'll be buying a Mac as soon as i am in a more
> comfortable financial situation to test some cross-platform
> capabilities.  i've always wanted one anyway =3D).

	I have a Powerbook and a PC running Linux (Gentoo). I expect to =
do=20
most of my work on OS X.

> To answer the two primary questions, I'm also in GMT-5 (Atlanta, GA
> US/Eastern).  also, i think freenode is the best network to use.  it =
is
> a development (primarily GNU/GPL stuff) network, and it already hosts
> such channels as #gnustep and others.  it is also the one that i am=20
> most
> frequently using.  of course, i could handle undernet, but i don't=20
> think
> we need the fluff of a generic network.  i encourage you guys to
> lurk/idle in #gnustep as well.

	OK, I'll be on #xsrcg. My online handle is Wild_Cat, by the way.

> glad to see that the list is active, and i'm glad to be in touch with
> you guys.

	Same here.

-- Max
maxnoel_fr at yahoo dot fr -- ICQ #85274019
"Look at you hacker... A pathetic creature of meat and bone, panting=20
and sweating as you run through my corridors... How can you challenge a=20=

perfect, immortal machine?"

Re: [xsrcg-devel] objective-c, the project, design, updates

[Adam B. <co...@di...>]

On Jun 15, 2004, at 03:59 PM, Jesse wrote:

> that's great that you use FreeBSD as well.  i was worried that the
> GNU/Linux/*BSD support might be an afterthought.  it's definitely
> doable, and not difficult.
>

Even though I don't use FreeBSD as much anymore, it's not forgotten. 
And with the Cocoa/GNUStep stuff I've always thought it would be best 
to try and program as cross-platform as possible. Which seems pretty 
doable, unless you get into some of the new fancy Cocoa stuff I guess.

> one of the first design topics i want to discuss is file formats.  not
> necessarily for the CharacterFiles yet, but for the data files that 
> feed
> SR data into the program.  we could *possibly* just use property lists.
> or we could use xml (or whatever you guys were thinking previously).  i
> was messing with propertylists a little bit today, and there are
> built-in class methods to read and write them to files (from<->to
> NSDictionarys and NSArrays).  quite nice.  if we can figure out a file
> format pretty early on, it would allow us to mess around with stuff a
> little further.  for example, i could write a quick program that helps
> to populate the SR database from user input and/or flat files.
>

We had talked about doing XML, I think. I'm really keen on the idea of 
doing XML. It might be easier to work with in the long run, and it will 
possibly make our stuff more portable.

As far as what kind of XML layout, we have a few options I guess. We 
could design our own XML spec, we could copy NSRCG's verbatim, or we 
could use the XML definitions that Wordman has on his site. I believe 
that the NSRCG stuff is a watered down version of the Wordman stuff, 
but don't quote me on that. It's just a guess from what I've read and 
understand about it.

I sort of lean towards possibly implementing the Wordman stuff. It's 
extremely complete and covers everything we'd need as a character 
generator, and then some. So we might possibly want to do a similar 
Lite version.

The url for it is http://www.divnull.com/lward/srun/xml/ . I'm not 
super up on XML, but I've gone over his spec to some degree and it 
seems pretty usable. It's just quite large, so that's a hurdle there. 
Although it can be broken down pretty easily.


> i am really hurting for a good SRCG, too =).  that brings me to a
> question:  have either of you gotten the windows srcg to work under
> wine?  i really *hate* booting to windows because i've always got
> something going on (program compiling, video encoding).  i would love 
> to
> get it running in wine.  the bump that i hit is in the INSTALL!  it
> seems to install, and then tells me it can't create the program group,
> and then it proceeds to UNINSTALL.  it's completely ridiculous.  i was
> able to get the files installed once, but then they didn't work because
> they were missing OCXs, which i assume should have been installed by 
> the
> INSTALL program.  also, getting this program working might help in our
> development.  i don't particularly care for the program (used it once 
> in
> windows on a friend's machine), but it serves as our only example, and
> could be helpful.
>

I haven't tried getting NSRCG going under WINE is a long time. At least 
a year or more easily. I don't think I was ever very successful, 
although I do think I did get it to run at some point. You might try 
downloading all of the VisualBasic runtimes that it uses, which I think 
are what those OCX files it's looking for are.

The installer he uses is a pretty dumb installer and it's always had 
various issues. Even on XP it's sometimes tough to get it installed 
properly.


> let me know if either of you have had any luck in that area.  i'm
> running wine 20040408.
>
> also, could one of you get me on the sf project?  my sf username is
> 'omie'.
>

You're added. I kept meaning to ask what your sf username was...heh.

--
Adam Brown
co...@di...

Re: [xsrcg-devel] objective-c, the project, design, updates

[Jesse <jwa...@sp...>]

cool.  i'm signed onto freenode most of the time.  i'm in #gnustep and
#xsrcg right now.  i notice that you're idling in there as well =).

that's great that you use FreeBSD as well.  i was worried that the
GNU/Linux/*BSD support might be an afterthought.  it's definitely
doable, and not difficult.

one of the first design topics i want to discuss is file formats.  not
necessarily for the CharacterFiles yet, but for the data files that feed
SR data into the program.  we could *possibly* just use property lists.
or we could use xml (or whatever you guys were thinking previously).  i
was messing with propertylists a little bit today, and there are
built-in class methods to read and write them to files (from<->to
NSDictionarys and NSArrays).  quite nice.  if we can figure out a file
format pretty early on, it would allow us to mess around with stuff a
little further.  for example, i could write a quick program that helps
to populate the SR database from user input and/or flat files.

i am really hurting for a good SRCG, too =).  that brings me to a
question:  have either of you gotten the windows srcg to work under
wine?  i really *hate* booting to windows because i've always got
something going on (program compiling, video encoding).  i would love to
get it running in wine.  the bump that i hit is in the INSTALL!  it
seems to install, and then tells me it can't create the program group,
and then it proceeds to UNINSTALL.  it's completely ridiculous.  i was
able to get the files installed once, but then they didn't work because
they were missing OCXs, which i assume should have been installed by the
INSTALL program.  also, getting this program working might help in our
development.  i don't particularly care for the program (used it once in
windows on a friend's machine), but it serves as our only example, and
could be helpful.

let me know if either of you have had any luck in that area.  i'm
running wine 20040408.

also, could one of you get me on the sf project?  my sf username is
'omie'.

-jesse
jwa...@sp...

On Tue, 2004-06-15 at 00:53 -0500, Adam Brown wrote:
> On Jun 14, 2004, at 11:35 PM, Jesse wrote:
> 
> > also, do you primarily use/develop linux or Mac OS X?  do you have both
> > platforms available?  i'll be buying a Mac as soon as i am in a more
> > comfortable financial situation to test some cross-platform
> > capabilities.  i've always wanted one anyway =).
> >
> 
> Hah, I never expected anyone would be buying a mac because of this 
> project. It's already a success as far as concerned. Time to move on. 
> :-P
> 
> > i primarily use linux, if you didn't know.  and also FreeBSD, but they
> > are virtually equivalent for our purposes.  but i'll be testing on
> > FreeBSD anyway.
> >
> 
> Just to clarify for myself here, I'm also a FreeBSD user, and was 
> almost exclusively prior to getting my powerbook and pretty much 
> abandoning all other computers I own. Although, I do have a FreeBSD 
> machine that's in serious need of some love that I can use to test 
> anything on as well. I think both of us using FreeBSD will be a Good 
> Thing.
> 
> > To answer the two primary questions, I'm also in GMT-5 (Atlanta, GA
> > US/Eastern).  also, i think freenode is the best network to use.  it is
> > a development (primarily GNU/GPL stuff) network, and it already hosts
> > such channels as #gnustep and others.  it is also the one that i am 
> > most
> > frequently using.  of course, i could handle undernet, but i don't 
> > think
> > we need the fluff of a generic network.  i encourage you guys to
> > lurk/idle in #gnustep as well.
> >
> 
> Alrighty, I've heard some good things about freenode, and since nothing 
> smart ever happens on undernet, I've moved on over. Feel free to log in 
> to #xsrcg on freenode then when you're one, perhaps we can 
> inadvertantly meet up if we don't get anything set up.
> 
> BTW, I'm officially in the US/Central timezone, which is normally 
> GMT-6, except when we're on daylight savings time. So, as far as I know 
> I'm still going to be an hour behind you, since I'm fairly sure Georgia 
> is under Daylight savings time. I hate daylight savings time, it's such 
> an annoyance.
> 
> Anyways, here's to hoping we can all get together on irc in the near 
> future.
> 
> --
> Adam Brown
> co...@di...
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
> Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
> Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
> REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
> _______________________________________________
> xsrcg-devel mailing list
> xsr...@li...
> https://lists.sourceforge.net/lists/listinfo/xsrcg-devel
> 
> 

Re: [xsrcg-devel] objective-c, the project, design, updates

[Adam B. <co...@di...>]

On Jun 14, 2004, at 11:35 PM, Jesse wrote:

> also, do you primarily use/develop linux or Mac OS X?  do you have both
> platforms available?  i'll be buying a Mac as soon as i am in a more
> comfortable financial situation to test some cross-platform
> capabilities.  i've always wanted one anyway =).
>

Hah, I never expected anyone would be buying a mac because of this 
project. It's already a success as far as concerned. Time to move on. 
:-P

> i primarily use linux, if you didn't know.  and also FreeBSD, but they
> are virtually equivalent for our purposes.  but i'll be testing on
> FreeBSD anyway.
>

Just to clarify for myself here, I'm also a FreeBSD user, and was 
almost exclusively prior to getting my powerbook and pretty much 
abandoning all other computers I own. Although, I do have a FreeBSD 
machine that's in serious need of some love that I can use to test 
anything on as well. I think both of us using FreeBSD will be a Good 
Thing.

> To answer the two primary questions, I'm also in GMT-5 (Atlanta, GA
> US/Eastern).  also, i think freenode is the best network to use.  it is
> a development (primarily GNU/GPL stuff) network, and it already hosts
> such channels as #gnustep and others.  it is also the one that i am 
> most
> frequently using.  of course, i could handle undernet, but i don't 
> think
> we need the fluff of a generic network.  i encourage you guys to
> lurk/idle in #gnustep as well.
>

Alrighty, I've heard some good things about freenode, and since nothing 
smart ever happens on undernet, I've moved on over. Feel free to log in 
to #xsrcg on freenode then when you're one, perhaps we can 
inadvertantly meet up if we don't get anything set up.

BTW, I'm officially in the US/Central timezone, which is normally 
GMT-6, except when we're on daylight savings time. So, as far as I know 
I'm still going to be an hour behind you, since I'm fairly sure Georgia 
is under Daylight savings time. I hate daylight savings time, it's such 
an annoyance.

Anyways, here's to hoping we can all get together on irc in the near 
future.

--
Adam Brown
co...@di...

Re: [xsrcg-devel] objective-c, the project, design, updates

[Jesse <jwa...@sp...>]

alright.  three's a good number =3D).  i think so, anyway.  Max, how much
experience do you have with objective-c/GNUstep/Cocoa?

also, do you primarily use/develop linux or Mac OS X?  do you have both
platforms available?  i'll be buying a Mac as soon as i am in a more
comfortable financial situation to test some cross-platform
capabilities.  i've always wanted one anyway =3D).

i primarily use linux, if you didn't know.  and also FreeBSD, but they
are virtually equivalent for our purposes.  but i'll be testing on
FreeBSD anyway. =20

To answer the two primary questions, I'm also in GMT-5 (Atlanta, GA
US/Eastern).  also, i think freenode is the best network to use.  it is
a development (primarily GNU/GPL stuff) network, and it already hosts
such channels as #gnustep and others.  it is also the one that i am most
frequently using.  of course, i could handle undernet, but i don't think
we need the fluff of a generic network.  i encourage you guys to
lurk/idle in #gnustep as well. =20

perhaps now we can coordinate some meeting times.  i will add that
school is very hectic for me lately.  i graduate in august, so i also
need to update my resume, get it to the career center, and get it out to
companies and hopefully have a job lined up by graduation.  i'm also
moving in the next couple of weeks (among tests and heavy homework
load!), so that will add to my busy schedule.

glad to see that the list is active, and i'm glad to be in touch with
you guys.

-jesse
jwa...@sp...

On Mon, 2004-06-14 at 22:06 -0500, Adam Brown wrote:
> On Jun 14, 2004, at 04:10 AM, Max Noel wrote:
>=20
> >
> > Le 14 juin 2004, =E0 05:53, Jesse Wattenbarger a =E9crit :
> >
> >> hey there,
> >>
> >> i don't know if anyone besides me and adam are on this list. but, oh
> >> well, someone needs to use it =3D).
> >
> > 	I'm there too. My name's Max. Pleased to meet you. ^^
> >
>=20
> And of course, me. I'm still here too!
>=20
> >> i've been hanging out in #gnustep on irc.freenode.org.  i know that
> >> we have a lot to do on design work before any real coding is begun,
> >> but i think getting a good grip on the language and API is giving me
> >> a good eye for design of the app.  maybe we should get together on
> >> irc some time and discuss the design a little bit.  school and an
> >> upcoming move have kept me pretty busy lately, but i'm still very
> >> interested in developing xsrcg.  it's gonna be a great app once we
> >> get around to it.  i want to make it the absolute best SR app
> >> available, and a damn good GNUstep/Cocoa cross-platform app =3D).
> >
> > 	Heh... That's the spirit!
> >
> > 	School is over for me, so I now have time to work on the project.=20
> > Meeting on IRC is a good idea, indeed, the question being "when?".=20
> > What are your respective timezones? (I'm in France, so that's GMT+1 --=20
> > +2 counting Daylight Savings Time)
> >
>=20
> School's over for me as well, but work has been pretty hectic lately.=20
> Apparently we're going to making an appearance at the NAMM show in=20
> Nashville next month, and lucky me gets to go. But with that, there's a=20
> lot of work we're doing to be prepared for the show and what not.
>=20
> Besides that, I've been trying to find a little time to get the Obj-C=20
> going. I've been reading some of the books I have here and there.
>=20
> IRC is always great. I'm usually idling somewhere. Any preferable=20
> networks? I usually avoid EFNet these days. I've been kind of idling=20
> around #S-Run on Undernet a bit lately, I'll go ahead and open up=20
> #xsrcg on Undernet as well. Unless you guys have a preferred network=20
> you already hang out on, which might be better than using Undernet=20
> (which I've never been partial too either).
>=20
> I'm in Oklahoma, so I guess I'm GMT-5 right now with daylight savings=20
> time in effect. Although my schedule is pretty flexible. Hopefully=20
> Jesse's not in Australia or something like that...heh. That would be a=20
> pain to get us all on IRC at the same time then. :-)
>=20
> --
> Adam Brown
> co...@di...
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
> Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
> Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
> REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
> _______________________________________________
> xsrcg-devel mailing list
> xsr...@li...
> https://lists.sourceforge.net/lists/listinfo/xsrcg-devel
>=20
>=20

Re: [xsrcg-devel] objective-c, the project, design, updates

[Adam B. <co...@di...>]

On Jun 14, 2004, at 04:10 AM, Max Noel wrote:

>
> Le 14 juin 2004, =E0 05:53, Jesse Wattenbarger a =E9crit :
>
>> hey there,
>>
>> i don't know if anyone besides me and adam are on this list. but, oh
>> well, someone needs to use it =3D).
>
> 	I'm there too. My name's Max. Pleased to meet you. ^^
>

And of course, me. I'm still here too!

>> i've been hanging out in #gnustep on irc.freenode.org.  i know that
>> we have a lot to do on design work before any real coding is begun,
>> but i think getting a good grip on the language and API is giving me
>> a good eye for design of the app.  maybe we should get together on
>> irc some time and discuss the design a little bit.  school and an
>> upcoming move have kept me pretty busy lately, but i'm still very
>> interested in developing xsrcg.  it's gonna be a great app once we
>> get around to it.  i want to make it the absolute best SR app
>> available, and a damn good GNUstep/Cocoa cross-platform app =3D).
>
> 	Heh... That's the spirit!
>
> 	School is over for me, so I now have time to work on the =
project.=20
> Meeting on IRC is a good idea, indeed, the question being "when?".=20
> What are your respective timezones? (I'm in France, so that's GMT+1 --=20=

> +2 counting Daylight Savings Time)
>

School's over for me as well, but work has been pretty hectic lately.=20
Apparently we're going to making an appearance at the NAMM show in=20
Nashville next month, and lucky me gets to go. But with that, there's a=20=

lot of work we're doing to be prepared for the show and what not.

Besides that, I've been trying to find a little time to get the Obj-C=20
going. I've been reading some of the books I have here and there.

IRC is always great. I'm usually idling somewhere. Any preferable=20
networks? I usually avoid EFNet these days. I've been kind of idling=20
around #S-Run on Undernet a bit lately, I'll go ahead and open up=20
#xsrcg on Undernet as well. Unless you guys have a preferred network=20
you already hang out on, which might be better than using Undernet=20
(which I've never been partial too either).

I'm in Oklahoma, so I guess I'm GMT-5 right now with daylight savings=20
time in effect. Although my schedule is pretty flexible. Hopefully=20
Jesse's not in Australia or something like that...heh. That would be a=20=

pain to get us all on IRC at the same time then. :-)

--
Adam Brown
co...@di...

Re: [xsrcg-devel] objective-c, the project, design, updates

[Max N. <max...@ya...>]

Le 14 juin 2004, =E0 05:53, Jesse Wattenbarger a =E9crit :

> hey there,
>
> i don't know if anyone besides me and adam are on this list. but, oh
> well, someone needs to use it =3D).

	I'm there too. My name's Max. Pleased to meet you. ^^

> i've been hanging out in #gnustep on irc.freenode.org.  i know that
> we have a lot to do on design work before any real coding is begun,
> but i think getting a good grip on the language and API is giving me
> a good eye for design of the app.  maybe we should get together on
> irc some time and discuss the design a little bit.  school and an
> upcoming move have kept me pretty busy lately, but i'm still very
> interested in developing xsrcg.  it's gonna be a great app once we
> get around to it.  i want to make it the absolute best SR app
> available, and a damn good GNUstep/Cocoa cross-platform app =3D).

	Heh... That's the spirit!

	School is over for me, so I now have time to work on the =
project.=20
Meeting on IRC is a good idea, indeed, the question being "when?". What=20=

are your respective timezones? (I'm in France, so that's GMT+1 -- +2=20
counting Daylight Savings Time)

-- Max
maxnoel_fr at yahoo dot fr -- ICQ #85274019
"Look at you hacker... A pathetic creature of meat and bone, panting=20
and sweating as you run through my corridors... How can you challenge a=20=

perfect, immortal machine?"

[xsrcg-devel] objective-c, the project, design, updates

[Jesse W. <jwa...@sp...>]

hey there,

i don't know if anyone besides me and adam are on this list. but, oh
well, someone needs to use it =).

i've been learning objective-c.  i love it.  it's quite nice.  wow, a
real object-oriented programming language!  don't know why i never
tried it out before.  i've been learning GNUstep as well (in the
little bit of spare time that i have).  it's also wonderful.  i'm
looking forward to buying a MAC pretty soon.  probably just a cheap
imac off of ebay.  

i've been hanging out in #gnustep on irc.freenode.org.  i know that
we have a lot to do on design work before any real coding is begun,
but i think getting a good grip on the language and API is giving me
a good eye for design of the app.  maybe we should get together on
irc some time and discuss the design a little bit.  school and an
upcoming move have kept me pretty busy lately, but i'm still very
interested in developing xsrcg.  it's gonna be a great app once we
get around to it.  i want to make it the absolute best SR app
available, and a damn good GNUstep/Cocoa cross-platform app =).

lemme know how things are going with _anyone_ else that's working on
this project.

omie
jwa...@sp...

[xsrcg-devel] testing.

[Jesse W. <jwa...@sp...>]

testing the list out again.  i think i signed up properly now =).

i will get back to you, and your post, later.  i've had a busy week.

omie

[xsrcg-devel] Testing...

[Adam B. <co...@da...>]

blah

-- 
Adam Brown <co...@ze...>
Nocturnal: The RPG -- http://dazed.zeppelin.net/connor
"Most people would rather die than think...in fact, most do."
		-- Bertrand Russell

[xsrcg-devel] Testing the list settings

[Adam B. <co...@di...>]

blah

--
Adam Brown
co...@di...

[xsrcg-devel] testing

[Jesse W. <jwa...@sp...>]

just testing the list out =).

[xsrcg-devel] Testing

[Adam B. <co...@di...>]

test

--
Adam Brown
co...@di...

[xsrcg-devel] Another test...

[Adam B. <co...@di...>]

blah^2

--
Adam Brown
co...@di...

[xsrcg-devel] Test Message

[Adam B. <co...@di...>]

blah

--
Adam Brown
co...@di...

[Xsrcg-devel] Testing the list...

[Adam B. <co...@di...>]

I figured I'd throw out a test email.

--
Adam Brown
co...@di...