[DGD] Persistent Users

[Gary Preston]

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