[DGD] Persistent Users

[Raymond Jennings]

LWOs should be treated like arrays and mappings in terms of references, but
like objects in terms of function calls

On Fri, Sep 23, 2016 at 10:21 AM, Gary Preston <gary at mups.co.uk> 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
>