Please let me know your thoughts...SLX Communication Framework series
-
Hi All, So after all this site has done for me, I think it is time to give back a bit. I've been developing this TCP communication framework on and off for a couple years, and we use it here internally for all our projects. It is essentially on complete rewrite #3, which seems to be when I get everything exactly how I want it. Brief overview: SLX Communication Framework lets you use a single modeling tool and framework to make all your .NET based apps talk to each other - full .NET Framework, Compact Framework, and Silverlight. The framework includes VS2008 code generators and visual designers. It has multiple levels of abstraction, each with their own suitable use cases: - Command-based object exchange API, built on: - Whole-Message exchange API, built on: - platform-independent sockets API I have at least 5 parts planned, possibly double that by the time I'm done...there is just a ton to talk about. So far on the drawing board for the content I want to cover: - who should read what - defining the problem - current options and associated limitations - my idea of an "ideal" communication framework, reasoning behind it - architecural overview of the actual framework, how it overcomes limitations of current options - explaining how each platform was abstracted to a common sockets API and related design decisions - very basic sample client/server app using the common sockets API - building the messaging API on top of the sockets API - very basic sample client/server app using the messageing API - building command-based generic object exchange API on top of the messaging API - building a VS2008 C#/VB code generator that parses the communication definition language and spits out the base classes and "fill in the blanks" methods - building VS2008 Client item template and Server item template - building a visual designer to graphically build your communication definition file - sample client/server application with silverlight, compact, and desktop clients that demonstrates how to implement ludicrous amounts of code sharing between all the projects I bet I can think of a few more things to throw in there as well. Basically, the point is that it is a very extensive framework and there are lots of angles to tackle things. It is fairly feature-complete right up to visual designers, code generators, etc, so someone looking to develop a different framework, even entirely unrelated, could possibly get a lot of useful information. But there is a LOT of potential information. So...questio
-
Hi All, So after all this site has done for me, I think it is time to give back a bit. I've been developing this TCP communication framework on and off for a couple years, and we use it here internally for all our projects. It is essentially on complete rewrite #3, which seems to be when I get everything exactly how I want it. Brief overview: SLX Communication Framework lets you use a single modeling tool and framework to make all your .NET based apps talk to each other - full .NET Framework, Compact Framework, and Silverlight. The framework includes VS2008 code generators and visual designers. It has multiple levels of abstraction, each with their own suitable use cases: - Command-based object exchange API, built on: - Whole-Message exchange API, built on: - platform-independent sockets API I have at least 5 parts planned, possibly double that by the time I'm done...there is just a ton to talk about. So far on the drawing board for the content I want to cover: - who should read what - defining the problem - current options and associated limitations - my idea of an "ideal" communication framework, reasoning behind it - architecural overview of the actual framework, how it overcomes limitations of current options - explaining how each platform was abstracted to a common sockets API and related design decisions - very basic sample client/server app using the common sockets API - building the messaging API on top of the sockets API - very basic sample client/server app using the messageing API - building command-based generic object exchange API on top of the messaging API - building a VS2008 C#/VB code generator that parses the communication definition language and spits out the base classes and "fill in the blanks" methods - building VS2008 Client item template and Server item template - building a visual designer to graphically build your communication definition file - sample client/server application with silverlight, compact, and desktop clients that demonstrates how to implement ludicrous amounts of code sharing between all the projects I bet I can think of a few more things to throw in there as well. Basically, the point is that it is a very extensive framework and there are lots of angles to tackle things. It is fairly feature-complete right up to visual designers, code generators, etc, so someone looking to develop a different framework, even entirely unrelated, could possibly get a lot of useful information. But there is a LOT of potential information. So...questio
5 parts sounds OK, but there is no upper limit. I can tell you that in the past when users approach me with highly detailed, well-outlined plans like this, and ask how many sections it should be released in, or if it is of interest to our users, the results are always the same: The articles do very, very well. An intro article sounds fine, and I'm sure however you decide to break it up, the articles will do, very, very well.
Thanks, Sean Ewington The Code Project