| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| | |
|
| | |
|
| |\
| |
| |
| |
| | |
rpc: authentication and basic handle manipulation
See merge request tpo/core/arti!1200
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
I've made doing some design choices here:
* Reserving "rpc" as a prefix for post-authentication
functionality that is not arti-specific.
* Declaring these to be methods on the session rather than methods
on the objects themselves.
There's a problem with defining an API to drop a weak reference; see
comment in code.
|
| |/
|
|
|
|
|
| |
Now that generation-arena has merged [@diziet's patch] to clarify
their license, we no longer need to disable it.
[@diziet's patch]: https://github.com/fitzgen/generational-arena/pull/56
|
| |
|
|
| |
This lets us simplify our logic a bit for strong references.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We want each ID to have a unique form every time it is given out,
so that you can't use ID==ID to check whether Object==Object. (See
discussions leading to #848.)
We'd also like the form of object IDs to be a little annoying to
analyze, to discourage people from writing programs that depends on
their particular format. (We are reserving the right to change the
format whenever we want.)
We _don't_ want to use any cryptography here (yet), lest somebody
think that this is an actual security mechanism. (This isn't for
security; it's for encouraging developers to treat IDs as opaque.)
With that in mind, we now lightly obfuscate our generational indices
before returning them.
|
| |
|
|
|
| |
These are about to become nondeterministic-ish and probably shouldn't
use the Into/TryFrom traits.
|
| |
|
|
|
|
|
|
| |
Per discussion referenced at #848, we want each operation that
returns a strong object ID to return a new, distinct strong ID.
Note that we no longer need to put strong and weak references in the
same arena; we can clean this code up a lot down the road.
|
| |
|
|
|
|
| |
Now we generate object IDs that we can parse. This is about to be
obsolete once we change how we generate objects and their IDs for #848,
but we may as well start from a working state.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Now there can be one of each, since we want references and handles
to be conceptually separate.
(The alternative would be to say that an operation either "returns a
handle" or "returns a reference (which may become a handle) unless a
handle already exists.")
|
| |
|
|
|
| |
This fake version is completely silly, but it will do the job until
we figure out our MPL2 concerns.
|
|
|
See the comments on `TypedAddr` for some explanations about
why this is so tricky. Thanks to @diziet for helping me figure
this out.
|
