02-15-2012, 06:27 PM
My questions is: why not have intercommunication? Why not allow people to manage their items and prices via the web interface? If not for this release, why not set up the framework for allowing it later on rather than locking yourself into periodic updates? There's no need to track prices and sales or have any real type of logging if everything is done immediately on the server and on the data that's already in memory and being used by everyone else. There would be absolutely no need for syncing anything at all.
Maybe it's because I work with WCF every single day, but I don't think there's anything more complex about setting up a WCF service than setting up a database and managing data that way. In fact, I think a database to do it is far more complex. If I can write 30 lines of code to host a WCF service inside RunUO that will search the exact same information as in-game and would be no different for Eru than writing any other script, why not go that route? Are you telling me searching world items in parallel using Linq2Objects is more difficult than writing a bunch of SQL to sync items?
WCF is the de factco way of exposing a web API in .NET 3.0+ and incredibly easy to set up. Scalability isn't the concern as much as simplicity while still allowing for growth. Simply serializing the data to a .json file every few minutes works, but it's limiting future ideas and only taking the complexity from like 30 lines of code to 10 lines of code. Whoopty ****ing do?
Plus... not having to write a single line of SQL is always a good thing, in my opinion.
But... really... my point wasn't as much WCF as much as searching items directly on the server in real time. Whatever you use to set up an API for that is trivial. I just think WCF is the simplest solution for that.
SQL being the worst solution might have been a bit of hyperbole on my part, but I definitely think it's a layer of complexity that isn't needed, whether the goal is searching live data or simply displaying periodically updated information.
Maybe it's because I work with WCF every single day, but I don't think there's anything more complex about setting up a WCF service than setting up a database and managing data that way. In fact, I think a database to do it is far more complex. If I can write 30 lines of code to host a WCF service inside RunUO that will search the exact same information as in-game and would be no different for Eru than writing any other script, why not go that route? Are you telling me searching world items in parallel using Linq2Objects is more difficult than writing a bunch of SQL to sync items?
WCF is the de factco way of exposing a web API in .NET 3.0+ and incredibly easy to set up. Scalability isn't the concern as much as simplicity while still allowing for growth. Simply serializing the data to a .json file every few minutes works, but it's limiting future ideas and only taking the complexity from like 30 lines of code to 10 lines of code. Whoopty ****ing do?
Plus... not having to write a single line of SQL is always a good thing, in my opinion.
But... really... my point wasn't as much WCF as much as searching items directly on the server in real time. Whatever you use to set up an API for that is trivial. I just think WCF is the simplest solution for that.
SQL being the worst solution might have been a bit of hyperbole on my part, but I definitely think it's a layer of complexity that isn't needed, whether the goal is searching live data or simply displaying periodically updated information.