[DGD] Persistent Users

[bart at wotf.org]

The interface it provides, and being able to keep that completely separate
from your actual account system are for me the main benefits from such an
approach, but I've used the caching idea you mentioned as well, but due to the
lwo copying, you can't actively call the lwo from the account daemon, it would
end up calling its own copy instead of the one in your user object, so when
that is a concern, and the data you cache is expensive to generate, you may
need to poll the account daemon to see if the user data has changed. This
easily ends up adding more cost then it saves, but it depends on how expensive
it is to regenerate the data. 

Anyway, what I like about the interface is that it keeps the lpc code which
uses it simple as you can just write it as if dealing with a simple mapping,
but at the same time it gives you full control over any access to the data,
oh, and it can be used to enforce a uniform access method to things like an
account system (which in that case should only accept external calls if they
come from a proxy object).

Bart.


On Fri, 23 Sep 2016 20:53:40 +0100, Gary wrote
> On 23/09/16 19:18, bart at wotf.org wrote:
> > Hi Gary,
> [snip]
> > 
> > You can also use an LWO as a proxy to talk to some daemon or service. By doing
> > this, you can often create a cleaner abstraction and hide everything behind
> > the proxy. Additionally, the proxy object can  ensure access checks happen 'at
> > the front door', and cache data where this poses no issue with regards to
> > modifications of that data.
> [snip]
> 
> I see what you mean now.
> 
> It's a hybrid of the two options I was considering. A proxy object with
> no data (avoids issues of LWO copying) but is also not a per field
> query-able LWO as it can just return a mapping from the AccountD 
> back to the caller.
> 
> That however makes me wonder if there's much gained by using the LWO
> proxy over directly querying AccountD->find_account(name) and receiving
> a copy of the mapping back?
> 
> Aside from being able to treat the entire mud account system as a
> mapping that is. Which in itself may be a good enough reason.
> 
> On the other hand, if the LWO represented one specific account's info
> and provided additional convenience methods, as a contrived example,
> assume it had a simple "fullname" function that concatenated and
> returned "first name" and "last name" from the mapping. Then it could
> cache the mapping returned by the AccountD and  operate on the cached
> data without additional AccountD related lookups.
> 
> Assuming of course there's a suitable way to invalidate the cache should
> the AccountD information be changed.
> 
> I suppose as far as account data goes, the access will likely be
> infrequent enough that if the pure proxy approach was taken, multiple
> lookups due to any additional convenience methods would be tolerable
> (avoiding having to manage a cache), but it seems like this style of
> design could crop up in other areas of the mud where avoiding extra
> lookups could be more important.
> 
> Regards,
> 
> Gary
> ____________________________________________
> https://mail.dworkin.nl/mailman/listinfo/dgd


--
http://www.flickr.com/photos/mrobjective/
http://www.om-d.org/