Hi,
Andrew Phelps wrote:
> In further reasoning of Miriam's theory...
>
> I would assume that you store the persistent state in a database of some
> type on the server...
Its all based on the Jini methodology, JavaSpaces is used for storing persistent
objects. JavaSpaces is a strange refreshing cross between a filesystem & Database
& RAM and its very low level, fe. to change a object you will have to take it and
write it
back into the space, there is no change method supported in fact there are only 4 main
methods supported: read(), take(), write(), notify(). Each transactions can be wrapped
in a "Atomic Transaction", with this you can let stuff happen inside the transaction
and because of its atomic nature nothing will happen if everything doesn't happen.
This could be very useful for future enhancement of the persistent platform to provide
for example enhanced security.
> Based on this assumption (which may or may not be the case) I would think
> that there could be a triggering mechanism such that a client could "pull"
> relevant information for all sectors that they are "near" (ie, could reach
> in x number of "moves"). My area of interest happens to be relational
> databases, but you could do this easily in a Java server as well.
At this stage there is no custom built server for the persistent bangSpace,
most of the "usual" server functions take place in the clients. To retrieve info
about sectors that are near we'll have to pull Sector Entries from the JavaSpace
manually. That is not a big problem because the Sector Entries don't contain
any content only info about the type of the entry and its Transform3D (pos/rot/sca).
> Say for instance that each "sector" stores itself in a row of a database,
> with the sector number as the primary or relational key. There are triggers
> on each row such that when the client requests that row, it receives that
> row first, and then rows 2-18 are "pushed" while the client explores area 1.
> That way, no matter where they go next, the info will already be there.
> Likewise the client could then throw it away after 4 or so turns of non-use
> since they could not get back to that sector without going back through a
> sector which would trigger it to re-load...
>
> Now this is really all dependent on HOW MUCH information we are talking
> about. Are we talking about a scene that downloads static and then updates
> to the persistent values based on a few numbers, or is each sector created
> on the fly from persistent information ? I guess I need a little more info
> to try and suggest possibilities.
I�m going to release beta1 on the 15. and its open-source with a lot of unsolved
exciting problems ;�
> Very interesting problem though, and good luck. For those of you following
> what I'm doing I think there will be a Clue Game 1.1 close to the end of
> this week / beginning of next.
Cool, I'll take a look.
Warm regards,
R�bert Vi�ar Bjarnason
[EMAIL PROTECTED]
