This project is read-only.

Joining the crew :)

Mar 22, 2009 at 11:52 AM

I have made some XEN improvements:


*changed IUpdate to IUpdatable (in can update itself)
*changed IDraw to IDrawable (it can draw itself)
*removed full namespace declarations to types
*removed conflicts with IDrawable Microsoft.Xna. interface
*added BaseDraw class
*Moved functionality related to Particle Systems to Xen
*XML commented above
*added new functionality to core Application class
*improved usability and code reusage
*removed IDraw from Resource interface
*removed all warnings
*tested all

I want to contribute it to you and be the partners. I have a great refactoring / documentation skills.

I have my own Serialization framework built on top on standart Xml .NET serialization (see ot on

So, I can use on-demand Xml serialization assembly generation.
I can write code for automatically serialize / deserialize data into the object trees.

XML db-> objects / objects -> XML db

Will you accepts this?

Can I post the these updates to you?

Mar 22, 2009 at 1:08 PM

Hello hack2root. You also emailed me the same message, so I'm going to repeat my reply to you:

I appreciate the effort you have put in, and that you are looking to improve the library, however some of the changes you have made I would not accept - and the others you aren't specific about what the changes are.

Please understand I have put a lot of effort and thought into many aspects of Xen's design. While it isn't perfect - and there are parts I'd like to change - backwards compatibility reasons, among others, prevent me from doing this. I have to balance the improvement a change will make, with the problems it will cause for people upgrading to a newer version (which, as times goes on, will become a larger portion of the userbase). Xen 1.5 has had nearly 400 downloads in a few weeks, and I expect roughly half of those will be upgrades from 1.4. If I make large scale changes that cause problems for people, I risk losing them as users. Ultimately I'm trying to make peoples lives easier :-)
This is less a problem for commercial and paid applications - free applications must build their reputation on stability, reliability and consistency.

The biggest issue I have is your desire to change from IDraw / IUpdate to IDrawable / IUpdateable. I choose these names for very specific reasons. The IDraw and IUpdate interfaces are the most important bits of code in the entire project - almost every part of the API ties into them in some way. Because of this, it has to be very simple and recognizable.
I went through *loads* of revisions on these two interfaces before I was happy with the result.
My initial intention was to call the IDraw interface IDrawable - likely for similar reasons to your own. However, I did not use this name. The primary reason was that XNA already uses this name in the Microsoft.Xna.Framework namespace - which is a very common namespace to reference. Using the same name would lead to *a lot* of confusion, and a lot of extra code to distinguish it. It would not be recognizable either.
Secondly, I feel IDrawable implies more about the object and the action it will take, where IDraw means (in my mind) the object is a part of the Draw process - but this is a minor issue in comparison.

IUpdate was chosen mostly for consistency with IDraw, however, the IUpdateable name is also in use in the XNA framework - so the same issue applies.
This would be such a wide reaching change that'd it'd surely cause *huge* problems. Let alone added to the problems I already mentioned.

I do not see the need for a BaseDraw class. Almost every app that will use Xen will implement their own variation on this class, tailored to the app. The interface is designed to be as minimal as possible, any attempt to build on this in specific ways will often give users false impressions of restriction. A users natural tendency will be to use the concrete class - which can only be more restrictive than the interface.

" *Moved functionality related to Particle Systems to Xen" - You do not specify what functionality you have moved. Xen is split into two projects (Xen and Xen.Ex) for very specific reasons. Xen is intended to be kept very minimal - and has seen very little external change since the very first version. Perhaps I'm missing something, but I don't see anything in the particle system that is a fundamental building block, like vertex buffers, thread tasks or the like, that would fit well in Xen.

*added new functionality to core Application class
*improved usability and code reusage

Once again, without specifics I can't really comment on these. I'm quite happy with the application class, it's a balance of minimalism with usefulness. It's certainly not perfect but it's something I haven't seen need to change. If you could tell me what you feel needs changing I'd be happy to consider it.

"*removed IDraw from Resource interface" - I'm really not sure what you mean by this one. The Resource class doesn't implement IDraw.

"*removed all warnings" - The code available on the website should compile without warnings.

I'll be honest and say I'm not interested in the serialization classes you have built. I'm not commenting the project or it's usefulness - I simply do not have any personal need for such a system, and I feel a large proportion of the people using Xen don't either. Perhaps I'm misinterpreting, but you seem to be suggesting I integrate it into xen - which I can say I have no intention of doing.

Once again. I do appreciate the effort and time you have put into making these changes, and I am not criticizing the work you have done. What I'm trying to show is there is a lot to consider when developing any open source code like this. One of the hardest things to do is to balance the many requirements of the project and resist the urge to add things too hastily. One of the hardest parts of programming is future thinking design and the ability to say no to changes.

When all is said and done, Xen is open source and free. You can do whatever you want with it. However, I will always have final say on the changes in my version of xen, and currently I don't feel you have made a compelling case for the benefit of those changes, especially considering the significant problems some of them introduce.

I'm certainly interested in your thoughts on the API and how you feel it could be better. As always I'm happy to take any suggestions into consideration.
Thanks, and good luck

- Graham