pEp/pEpForiOS
8
0
Fork
You've already forked pEpForiOS
0

FEATURE-4: download from keyserver manually #5

Closed
fdik wants to merge 0 commits from FEATURE-4 into master
pull from: FEATURE-4
merge into: pEp:master
pEp:master
pEp:dz/iOS_SDK_18_5
pEp:dz/no_aligned_collection_view_flow_layout
pEp:FEATURE-2
pEp:dz/wire_up_vks_automation
pEp:dz/adapter_as_static_library
pEp:rebuild
Owner
Copy link

Hi, Dirk

If there is no problem please merge.

Hi, Dirk If there is no problem please merge.
@ -65,2 +93,4 @@
}
private func navigationItemTitleView(pEpRating: Rating?, pEpProtection: Bool = true) -> UIView? {
if let img = pEpRating?.pEpColor().statusIconForMessage(enabled: pEpProtection) {
Owner
Copy link

The if-else here now mixes UI-concerns (image exists or not?) with rating logic.

Maybe something like this?

if pEpRating == Rating.unencrypted && keyserverSupport {
 // key server icon, if exists
} else {
 // the status icon, if exists (original code)
}
The if-else here now mixes UI-concerns (image exists or not?) with rating logic. Maybe something like this? ``` if pEpRating == Rating.unencrypted && keyserverSupport { // key server icon, if exists } else { // the status icon, if exists (original code) } ```
Author
Owner
Copy link

The code is correct. There are two cases when we need code:

  1. There is a color, then we need an Image for it.
  2. Else if there is no color, only if the rating is unencrypted (and not in any other no-color case) we need the keyserver icon.

What is the problem with this?

The code is correct. There are two cases when we need code: 1. There is a color, then we need an Image for it. 2. Else if there is no color, only if the rating is unencrypted (and not in any other no-color case) we need the keyserver icon. What is the problem with this?
@ -0,0 +25,4 @@
return
} successCallback: { ident in
do {
try session.vksRetriveKey(for: ident)
Owner
Copy link

This is network, right? I think the adapter serializes all calls on one queue in its default session interface, and until the callbacks are handled no other adapter call is possible.

This is network, right? I think the adapter serializes all calls on one queue in its default session interface, and until the callbacks are handled no other adapter call is possible.
Author
Owner
Copy link

The code actually worked. I tried it out. What is the issue?

The code actually worked. I tried it out. What is the issue?
Owner
Copy link

I think that any other queue using the adapter is blocked until the success callback here is finished. Of course, we could try to make the internal adapter queue concurrent to avoid problems like this. I don't remember if there were issues with a concurrent queue.

I think that any other queue using the adapter is blocked until the success callback here is finished. Of course, we could try to make the internal adapter queue concurrent to avoid problems like this. I don't remember if there were issues with a concurrent queue.
Author
Owner
Copy link

We could change session.vksRetrieveKey() having a success and a failure block itself. What do you think?

We could change session.vksRetrieveKey() having a success and a failure block itself. What do you think?
Owner
Copy link

Ok, will do.

Ok, will do.
Owner
Copy link

The tests don't compile, I guess because of the new setting.

The tests don't compile, I guess because of the new setting.
Author
Owner
Copy link

I did not yet touch the tests, so this is absolutely possible.

I did not yet touch the tests, so this is absolutely possible.
Author
Owner
Copy link

@dirkz BTW, the p≡p engine is meant to be used in parallel. It must be initialized with the first init() and other calls to init() must only appear after the first init() is done. But then it is meant to be called once per thread. PEP_SESSION is meant to be stored in thread local storage. And when a (worker) thread shuts down, release() must be called on this thread. The last release() must be called after all other release() calls are done already. Would it be possible to change the adapter to execute like this?

@dirkz BTW, the p≡p engine is meant to be used in parallel. It must be initialized with the first init() and other calls to init() must only appear after the first init() is done. But then it is meant to be called once per thread. PEP_SESSION is meant to be stored in thread local storage. And when a (worker) thread shuts down, release() must be called on this thread. The last release() must be called after all other release() calls are done already. Would it be possible to change the adapter to execute like this?
Owner
Copy link

@fdik wrote in #5 (comment):

@dirkz BTW, the p≡p engine is meant to be used in parallel. It must be initialized with the first init() and other calls to init() must only appear after the first init() is done. But then it is meant to be called once per thread. PEP_SESSION is meant to be stored in thread local storage. And when a (worker) thread shuts down, release() must be called on this thread. The last release() must be called after all other release() calls are done already. Would it be possible to change the adapter to execute like this?

Yes, certainly. It's mostly already like this, except in practice most actions on the session are serialized, for reasons I don't remember.

@fdik wrote in https://codeberg.org/pEp/pEpForiOS/pulls/5#issuecomment-11873538: > @dirkz BTW, the p≡p engine is meant to be used in parallel. It must be initialized with the first init() and other calls to init() must only appear after the first init() is done. But then it is meant to be called once per thread. PEP_SESSION is meant to be stored in thread local storage. And when a (worker) thread shuts down, release() must be called on this thread. The last release() must be called after all other release() calls are done already. Would it be possible to change the adapter to execute like this? Yes, certainly. It's mostly already like this, except in practice most actions on the session are serialized, for reasons I don't remember.
Owner
Copy link

We can probably just merge this and go from there. I will fix the tests and work on the adapter then. @fdik Ok with you?

We can probably just merge this and go from there. I will fix the tests and work on the adapter then. @fdik Ok with you?
Owner
Copy link

Merged, all tests green.

Merged, all tests green.
dirkz closed this pull request 2026年03月21日 13:58:53 +01:00

Pull request closed

Please reopen this pull request to perform a merge.
Sign in to join this conversation.
No reviewers
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
pEp/pEpForiOS!5
Reference in a new issue
pEp/pEpForiOS
No description provided.
Delete branch "FEATURE-4"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?