[Arianne-bugs] [ arianne-Feature Requests-3007147 ] [Marauroa] Interfaces

[SourceForge.net <no...@so...>]

Feature Requests item #3007147, was opened at 2010-05-26 00:43
Message generated for change (Comment added) made by javydreamercsw
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=351111&aid=3007147&group_id=1111

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Javier A. Ortiz Bultron (javydreamercsw)
Assigned to: Nobody/Anonymous (nobody)
Summary: [Marauroa] Interfaces

Initial Comment:
This has no effect on the rest of the code but provides an API for extending the game

----------------------------------------------------------------------

>Comment By: Javier A. Ortiz Bultron (javydreamercsw)
Date: 2010-05-27 04:51

Message:
Well in my case I have the Client Object defined as an interface and is
instantiated at run time. So the code is generic enough to call actions on
objects with implementing that interface. That provides me way of having
one server being used for games and document systems without changing the
core logic.

Right now all implementations using Marauroa are like this (in layers):

1. Marauroa (RPObject)
2. App Servercode (Object extending RPObject)
3. App client(Consume/update the Object extending RPObject)

I managed to merge layers 1 and 2 with this approach.

You can take a look at Simple-Marauroa project:

1. Marauroa (RPObjectInterface)
2. App client(Consume/update the RPObjectInterface)

So far I'm not needing RPEvent, RPSlot and such because they are 100%
configurable using the Marauroa API.


----------------------------------------------------------------------

Comment By: Hendrik Brummermann (nhnb)
Date: 2010-05-26 21:20

Message:
Hi Javier,

I have to admit that I do not understand the purpose of these interfaces.

You mentioned somewhere that is is about database storage. The database
storage code, however, is in RPObjectDAO [1].


Within Attribute and RPObject, however, is the networking code. If someone
provides another implementation of RPObject it will be very difficult to
ensure compatibility on the network layer.

You mentioned "the game" in the description. Which one?

Are games supposed to use the interface instead of the implementation when
they extend RPObject and then forward all the methods to an actual
implemenation?

What about the other related classes RPLink, RPSlot, RPEvent?

How does instantiation of the correct implementation work?


_________________________________________________________________________
[1] RPObjectDAO currently uses the network serialized form as blob. There
are two pre-requirement for starting to work on meta model storage:
Asynchronous database access for reading and writing characters which is
required for performance reason. This has been implemented in the upcoming
Marauroa 3.7. A sane solution for abusing a single RPObject in a slot as
untyped map storage.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=351111&aid=3007147&group_id=1111