Menu
News
All News
Dungeons & Dragons
Level Up: Advanced 5th Edition
Pathfinder
Starfinder
Warhammer
2d20 System
Year Zero Engine
Industry News
Reviews
Dragon Reflections
White Dwarf Reflections
Columns
Weekly Digests
Weekly News Digest
Freebies, Sales & Bundles
RPG Print News
RPG Crowdfunding News
Game Content
ENterplanetary DimENsions
Mythological Figures
Opinion
Worlds of Design
Peregrine's Nest
RPG Evolution
Other Columns
From the Freelancing Frontline
Monster ENcyclopedia
WotC/TSR Alumni Look Back
4 Hours w/RSD (Ryan Dancey)
The Road to 3E (Jonathan Tweet)
Greenwood's Realms (Ed Greenwood)
Drawmij's TSR (Jim Ward)
Community
Forums & Topics
Forum List
Latest Posts
Forum list
*Dungeons & Dragons
Level Up: Advanced 5th Edition
D&D Older Editions
*TTRPGs General
*Pathfinder & Starfinder
EN Publishing
*Geek Talk & Media
Search forums
Chat/Discord
Resources
Wiki
Pages
Latest activity
Media
New media
New comments
Search media
Downloads
Latest reviews
Search resources
EN Publishing
Store
EN5ider
Adventures in ZEITGEIST
Awfully Cheerful Engine
What's OLD is NEW
Judge Dredd & The Worlds Of 2000AD
War of the Burning Sky
Level Up: Advanced 5E
Events & Releases
Upcoming Events
Private Events
Featured Events
Socials!
EN Publishing
Twitter
BlueSky
Facebook
Instagram
EN World
BlueSky
YouTube
Facebook
Twitter
Twitch
Podcast
Features
Top 5 RPGs Compiled Charts 2004-Present
Adventure Game Industry Market Research Summary (RPGs) V1.0
Ryan Dancey: Acquiring TSR
Q&A With Gary Gygax
D&D Rules FAQs
TSR, WotC, & Paizo: A Comparative History
D&D Pronunciation Guide
Million Dollar TTRPG Kickstarters
Tabletop RPG Podcast Hall of Fame
Eric Noah's Unofficial D&D 3rd Edition News
D&D in the Mainstream
D&D & RPG History
About Morrus
Log in
Register
What's new
Search
Search
Search titles only
By:
Forums & Topics
Forum List
Latest Posts
Forum list
*Dungeons & Dragons
Level Up: Advanced 5th Edition
D&D Older Editions
*TTRPGs General
*Pathfinder & Starfinder
EN Publishing
*Geek Talk & Media
Search forums
Chat/Discord
Menu
Log in
Register
Install the app
Install
Community
General Tabletop Discussion
*Geek Talk & Media
A standard RPG gaming API
JavaScript is disabled. For a better experience, please enable JavaScript in your browser before proceeding.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an
alternative browser
.
Reply to thread
Message
<blockquote data-quote="towngen" data-source="post: 424005" data-attributes="member: 1528"><p>Between all the different ideas here on this thread I'm not exactly sure where we stand right now. I kinda like smetzger's idea of: just do something. But I'd hate to start out in the wrong direction and have to redo everything.</p><p></p><p>Perhaps I/we ought to work on a subset of the problem first, then expand it once something concrete actually exists. Some people watching this discussion are probably beginning to think this will amount to nothing but wishful thinking and extremely excellent theoretical vaporware.</p><p></p><p>With my current school schedule (why did I decide to take 10 hours this semester?) and the demands of my job, it's going to take me some time just to get started.</p><p></p><p>Since I don't know beans about Mac and Linux, the only thing that I personally can do is start implementing a windows version of the session layer that will sit on top of TCP/IP. This layer will not know what kind of objects are being requested or sent. It will simply establish and validate connections, and provide a platform specific (windows) interface for it. Once a specific protocol is worked out for windows, then it could be implemented for other platforms.</p><p></p><p>I guess XML is the idea solution for the presentation layer, even if TCP/IP turns out to be less than perfect for the session layer. If someone wants to start designing this layer, you could do so even before anything is finished with the session layer. You can assume that you will receive an ASCII text string containing something from another application. And you can ignore (for now anyway) issues of how to "dial up" another application (either local or remote). The session layer will deal with that. This layer will have to figure out what the message is and what to do with it. Is it the answer to a previous request, or is it a request and if so a request for what? This layer will also have to package up local data (requests or answers to requests) for transmission via the session layer.</p><p></p><p>Can someone work out the basics for the presentation layer for handling a request and answer to a relatively simple object? Once a basic version of a presentation layer is developed, it could be tested with the session layer in a simple test application. Once it's working, then the two layers could be alpha released so other people can add other objects into the definition. Once that is tested some, then we can release a first version of this thing.</p><p></p><p>If things turn out poorly for TCP/IP, the perhaps we can change the form of the session layer to some other methodology. The same goes for XML in the presentation layer. Also, we don't have to implement every possible function in the session layer to start with. We can start with a simple local only connection, then build from there.</p><p></p><p>Does this sound like a halfway reasonable plan to start actually accomplishing something? Anyone wish to suggest a better plan of action? Also, there is no reason that we can't start down 2 paths right now, and decide after there is something concrete which to choose to go with. Or is there a reason why we can't do that? Any thoughts? Better ideas? Do multiple groups want to work on this in parallel to improve the chances we will actually finish this? Do we want to try multiple ideas and test how they perform?</p></blockquote><p></p>
[QUOTE="towngen, post: 424005, member: 1528"] Between all the different ideas here on this thread I'm not exactly sure where we stand right now. I kinda like smetzger's idea of: just do something. But I'd hate to start out in the wrong direction and have to redo everything. Perhaps I/we ought to work on a subset of the problem first, then expand it once something concrete actually exists. Some people watching this discussion are probably beginning to think this will amount to nothing but wishful thinking and extremely excellent theoretical vaporware. With my current school schedule (why did I decide to take 10 hours this semester?) and the demands of my job, it's going to take me some time just to get started. Since I don't know beans about Mac and Linux, the only thing that I personally can do is start implementing a windows version of the session layer that will sit on top of TCP/IP. This layer will not know what kind of objects are being requested or sent. It will simply establish and validate connections, and provide a platform specific (windows) interface for it. Once a specific protocol is worked out for windows, then it could be implemented for other platforms. I guess XML is the idea solution for the presentation layer, even if TCP/IP turns out to be less than perfect for the session layer. If someone wants to start designing this layer, you could do so even before anything is finished with the session layer. You can assume that you will receive an ASCII text string containing something from another application. And you can ignore (for now anyway) issues of how to "dial up" another application (either local or remote). The session layer will deal with that. This layer will have to figure out what the message is and what to do with it. Is it the answer to a previous request, or is it a request and if so a request for what? This layer will also have to package up local data (requests or answers to requests) for transmission via the session layer. Can someone work out the basics for the presentation layer for handling a request and answer to a relatively simple object? Once a basic version of a presentation layer is developed, it could be tested with the session layer in a simple test application. Once it's working, then the two layers could be alpha released so other people can add other objects into the definition. Once that is tested some, then we can release a first version of this thing. If things turn out poorly for TCP/IP, the perhaps we can change the form of the session layer to some other methodology. The same goes for XML in the presentation layer. Also, we don't have to implement every possible function in the session layer to start with. We can start with a simple local only connection, then build from there. Does this sound like a halfway reasonable plan to start actually accomplishing something? Anyone wish to suggest a better plan of action? Also, there is no reason that we can't start down 2 paths right now, and decide after there is something concrete which to choose to go with. Or is there a reason why we can't do that? Any thoughts? Better ideas? Do multiple groups want to work on this in parallel to improve the chances we will actually finish this? Do we want to try multiple ideas and test how they perform? [/QUOTE]
Insert quotes…
Verification
Post reply
Community
General Tabletop Discussion
*Geek Talk & Media
A standard RPG gaming API
Top