1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
//! The PLM client: where the server is, how a request reaches it, and — in
//! `client` — sign-in, the refusals, the change feed and the version check.
//! Nothing here runs unless a server is configured; the file-based app never
//! constructs any of it.
// The pure halves of S5 (uses lists) and S13 (adoption): no transport, no
// store writes — the publisher and the importer drive them.
/// Embedded copies of PLM parts as a cache of their revisions (refreshed on open).
/// Embedded copies pinned to a superseded or obsolete PLM revision.
/// The bake worker (S10): open a queued member, build it, report.
/// Families and templates on a PLM store (S9): Generate, members, spin-out.
/// Parts with no document of their own become items (an assembly's Save).
/// Revision thumbnails (P9): the picture a save makes and uploads.
/// The instructions player's data a save of an instructions revision makes
/// and uploads.
/// One HTTP exchange with the PLM, whatever carries it. `path` is relative to
/// the server's base URL (`"/api/store/index"`); the client, not the
/// transport, adds the credential headers.
/// The server's answer, whatever its status.
/// Deliberately not `Send`, like the store seam's `BackendFuture`: every host
/// is single-threaded (the browser main thread; the native frame loop).
pub type PlmFuture<T> = Pin;
/// Carries a [`PlmRequest`] to the server. `Err` means the request never got
/// an answer (network, DNS, refused connection). Every HTTP status — 204, 4xx
/// and 5xx included — is `Ok`; the client maps them.