Next up: Sandbox mode for TWXProxy
Don Brown
mode, where upon connection, TWX Proxy will already be connected to
TWGS and the correct database will be loaded. The menu options for
disconnecting from TWGS and switching games would be disabled, which
aren't necessary if you are using a different front-end, and it would
also minimize any security risk of traders getting access to each
other's data.
The flag from the command line would be "/S" for sandbox and would
rely on an INI file to supply the game details.
Any objections?
Don
EP
loading the proper one after authentication. This could even entail a
db for each user for each game on the server. Not that these
databases are large, but they will need to be named with this in mind.
The idea behind the sandbox mode is a smaller footprint, essentially
an instance designed to be embedded. The only objection I have is
calling it sandbox mode, rather than minimal or embedded :P
See, the /min switch makes much more sense to me.
EP
Don Brown
>
> Each TWX instance will need to have access to every user's database,
> loading the proper one after authentication. This could even entail a
> db for each user for each game on the server. Not that these
> databases are large, but they will need to be named with this in mind.
I was thinking a simpler solution would be to make the data directory
configurable, probably via the ini file. Therefore, we could give
every user their own data directory without worrying about data
leaking.
>
> The idea behind the sandbox mode is a smaller footprint, essentially
> an instance designed to be embedded. The only objection I have is
> calling it sandbox mode, rather than minimal or embedded :P
>
> See, the /min switch makes much more sense to me.
Well, sandbox mode will do more than just make it small. I'm thinking
it would disable certain menu options like disconnect and switching
database and simplify login. I guess you could just tie those
concepts together, so as long as it is clear what /min mode is, I'm
fine with it.
Don
EP
"Cache Database in available memory" option, then that can be used in
lieu of a /min option, as that should accomplish most of the footprint
reduction that I had in mind. In 2.04, I chose speed over memory
conservation, and paid no attention to that toggle. I also didn't
(don't) fully understand the warp cache that Xide used, so I made my
own along side of it. The result is that warp data is really cached
twice, though I think Xide's was used for WarpIn lookups.
One thing I'd like to accomplish in the next release is to add a
warpin cache to improve those lookups (in a way I understand), and
make both warp and warpin caches dependant on the "Cache Database..."
switch, like Xide had it. Or better yet, don't build the warp /
warpin cache until the first time it is needed, and then have it
persist until that session is closed, and do away with the toggle
altogether.
EP
Don Brown
>
> Perhaps if we add the option in the ini file to enable/disable the
> "Cache Database in available memory" option, then that can be used in
> lieu of a /min option, as that should accomplish most of the footprint
> reduction that I had in mind. In 2.04, I chose speed over memory
> conservation, and paid no attention to that toggle. I also didn't
> (don't) fully understand the warp cache that Xide used, so I made my
> own along side of it. The result is that warp data is really cached
> twice, though I think Xide's was used for WarpIn lookups.
Perfect, let's do it. I'm determining the INI sections based on what
class it pertains to, so pick the appropriate one (TWXServer or
whatever) and add the option.
Don