I guess I should make sure one of my pre-conceptions comes across clearly: When I think of the account object, I think of it as three things:

• the authoritative source for credentials (namely, the token)
• the source for info about roles
• the source for the service catalog

So when I think of it, I view it as the piece that provides the basic configuration parameters for all of the other services to function correctly.

Hi,

This indeed seems like a nice way to do this. I actually really like this. It's practically the same API besides constructing the various endpoints and passing the token between them.

However, I eventually wanted to add something like parsing the expires token and sticking a goroutine on a <-time.After() call which will then re-authenticate. The reason for this is that since Go is intended to be server-side and I am writing apps which will be long-lived. I don't want to have to make re-authenticate calls.

How would you get around that approach? Maybe internally they could have something like:

/* Unexported */
type authentication struct {
    auth_token string
    m          sync.Mutex
    /* Any other required fields */
}

func (a authentication) authenticate() string {
    a.m.Lock()
    defer a.m.Unlock()
    return a.auth_token
}

func (a *authentication) watch_for_timeout(timestring string) {
    t := parseTimestring(timetsring)
    go func() {
        for {
            <-time.After(t)
            a.m.Lock()
            re_authenticate(a)
            a.m.Unlock()
        }
    }()
}

func Authenticate(u, p, t string) *Account {
    /* Authenticate here */
    a := &authentication{auth_token: response.Token}
    a.watch_for_timeout(timeoutstring)
    acc.authentication = a
}

func NewFromAccount(a authentication /* whatever else */) ObjectStore {
    os := new(ObjectStore)
    os.authentication = a
    os.url = url
}

That's a quick bit of code (it probably (definitely!) won't compile). The assumed function is parseTimestring.

Thoughts on something like this? Otherwise de-authentication/token expiry requires explicit checking of response codes (and subsequent re-creation of all other module values.)