[DGD] Persistent Users

[bart at wotf.org]

Hi Gary,

One of the advantages of LWOs is the support for operator overloading, which
means you can for example make an LWO behave like it is an array or mapping or
such. That is more syntactic sugar then anything, but it can help making your
code easier to understand and manage.

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.


For example:

You could create an LWO which does not contain any data, but contains some
code, including 2 functions which overload the [] and []= operators.

This object talks to the account daemon, this could look as follows:

/* a tiny proxy LWO */

static mixed operator [] ( string name ) {
   return account_d->get_user_data( name );
}

static void operator []= ( string name, mixed data ) {
   account_d->set_user_data( name, data );
}

/* end of code */

Now, when something wants to talk to the account system, it should use
new_object to get a copy of this LWO, ie:

object account;

account = new_object( find_object( "path to your lwo" ) );

Now, you can simply write things like account["username"] to refer to the data
for that user. The LWO will take care of actually talking to the account system.

I'd myself return a 'deep copy' of the account data from the [] function, to
ensure code must always go through the []= function to change things. Ie, the
user object can get the mapping with account info for the user it works for,
but when changing something, modifying that mapping will not be enough.. you
have to do a account["name"] = mapping_with_info;

Of course, this example is a bit simplistic, you may want to add some extra
checks in there. 

The only reason really for doing this is that from any code outside the
account system, you can use this as if it is just a huge mapping, all the
details for how it works can be hidden.

Each user object having its own copy of the LWO doesn't matter, it only
contains a tiny bit of code, and talks to a centralized daemon for the real stuff.

Bart.

On Fri, 23 Sep 2016 18:21:55 +0100, Gary Preston wrote
> On 22/09/16 19:00, bart at wotf.org wrote:
> [snip]
> >>
> >> The ACCOUNTD can then make use of a mapping of arrays, or abstract away
> >> the splitting of storage between multiple objects. That would allow a
> >> naive accountd implementation of a single mapping or array yet retain
> >> the option to migrate to separate objects that accountd manages and
> >> avoid changes to the kernel library as USERD will once more only 
> >> track online and link dead users.
> > 
> > Sounds like a viable approach to me. You could opt to use an LWO with operator
> > overloading to simulate indices on a mapping, and use that from within USER_D
> > to talk to your account daemon. That will let you write most of the code as if
> > it is just a mapping, and abstract away whatever you do to distribute the data
> > over multiple mappings or arrays or objects.
> >
> 
> I've yet to really use LWOs so I may be misunderstanding your
> suggestion. I can think of a couple of implementation options and I'm
> not sure which (if any) you were suggesting:-
> 
> # Option 1
> 
> If AccountD->find_account(name) returns an LWO, then that LWO could
> hold no data (beyond perhaps immutable account_name), that would 
> allow any caller of find_account to retain the LWO beyond the 
> current execution thread as there's no problem with the LWO ending 
> up a copy once the current thread ends (it has no data that could be 
> out of date if anything else makes changes to the current account's 
> info in the AccountD).
> 
> However, it does mean if the user object accessed the account_info 
> LWO to check password, then last_login then some other account field,
>  that each access would require a call_out into AccountD and in turn 
> an internal lookup of the account name made to find the required data.
> 
> # Option 2
> 
> The alternative would be for the LWO AccountD->find_account returns 
> to actually hold the account data as data fields within the object. Then
> the User object can read-only access any of the account_info fields
> without any call out to the AccountD and only when making changes would
> the LWO need to hand off to the AccountD.
> 
> That however implies that the User does not retain a reference to the
> LWO beyond the current execution thread as the LWO would end up becoming
> a copy and there would be no way to know if the data it holds is 
> stale or not (since other code may have modified data in AccountD).
> 
> Were you referring to either of the above options, or another variation?
> 
> Another alternative would perhaps be for AccountD to return normal
> cloned account_info objects. Then even if several different objects call
> AccountD->find_account("gary") and retain a reference to that object,
> they would all be reading/changing the same data.
> 
> Whilst I understand the "limitations" of light-weight objects in 
> terms of no need to destruct, garbage collected, no call_outs onto 
> it etc I'm not clear on whether there's any other advantages to them 
> beyond the need to not explicitly destruct them? So I'm not quite 
> sure whether returning clones for account_info or LWOs would be preferable?
> 
> Given a bit more thought I'll probably come to a decision on this, 
> but I'm curious as to what you were suggesting, just in case I've overlooked
> a better alternative.
> 
> Note: All of the above is ignoring exactly how the AccountD will 
> store account data which would take into account the prior 
> discussion on not having any one array/mapping too large and 
> potentially splitting across objects. Instead I'm more concerned 
> with the interface to the AccountD.
> 
> Regards,
> 
> Gary
> ____________________________________________
> https://mail.dworkin.nl/mailman/listinfo/dgd


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