HTTP Proxy Jump Service Features

[coneiric]

---

By submitting this issue, I confirm the following:

• I have read and understood the contributor guide in kovri-docs.
• I have checked that the issue I am reporting can be replicated or that the feature I am suggesting is not present.
• I have checked opened or recently closed pull requests for existing solutions/implementations to my issue/suggestion.

---

After looking through the TODOS 1 2 for HTTPMessage::HandleJumpService, I came up with some ideas for a redesign.

edit: add prerequisite issues, reformat as task list

Below are what I understand to be the required features of the jump service handler.
Some are already implemented, others are new proposals:

• load entries from multiple host files (requires resolution of Improve Address Book #305 / AddressBook: discuss/implement multiple subscription files #337)
• add new host entry (requires resolution of Improve Address Book #305 )
• check address not already in: (requires resolution of Improve Address Book #305 / AddressBook: discuss/implement multiple subscription files #337)
  • hosts.txt
  • private_hosts.txt
  • subscription-specific hosts files
• prompt user to save new host entry
• display information of host entry being added
  • short hostname (host-name.i2p)
  • base32 address (long-b32-string.b32.i2p)
  • full base64-encoded destination information (base64 blob)
• provide information on save location options (requires resolution of Improve Address Book #305 / AddressBook: discuss/implement multiple subscription files #337)
  • private_hosts.txt, service_hosts.txt, etc.
• provide option to cancel saving new entry
• replace ByteStream instances with modular & secure interface, in pursuit of Remove or improve I/O ByteStream? #811
• convert HTTPMessage::HandleJumpService() to bool return for testing
• unit tests (pass existing tests, and write new tests)
• what can be implemented before Discuss database solution for address book, netdb, profiles, etc. #385 is resolved? (may be solved by resolution of Improve Address Book #305 / AddressBook: discuss/implement multiple subscription files #337)
  • treat storage implementation as blackbox
  • handle reading & writing with modular interfaces
  • use / write new interfaces independent of storage implementation (maybe?)

Related Kovri source files:

• HTTP Proxy impl and header
• Address Book impl and header
• Output/Input ByteStream impl and header
• HTTP Proxy unit tests
• Address book unit tests

Related Java2P source files:

• Host.txt Entry class
• Hosts.txt Naming Service
• NamingService class
• Single Host.txt Naming Service

Referencing #305 #337 #338 #811

[anonimal]

load entries from multiple host files
add new host entry
check address not already in:
hosts.txt
private_hosts.txt
subscription-specific hosts files

These features must be resolved in #305/#337 before they are resolved here.

replace stream instances with cryptopp pipelines, in pursuit of #811

Don't confuse i2p streaming with byte streaming - they are very different.

treat storage as blackbox

Subscriptions are meant to be shared, what do you mean by this?

[coneiric]

These features must be resolved in #305/#337 before they are resolved here.

Happy to start working on those issues first, or in parallel with jump service features that don't depend on loading from multiple hosts files. I'll edit the OP to indicate dependent issues.

Don't confuse i2p streaming with byte streaming - they are very different.

I was confusing them, thanks for the heads up.

Subscriptions are meant to be shared, what do you mean by this?

I was referring to discussion in #385 about a possible database or openldap implementation for various components. So, to cut down on refactoring, I was trying to think of a way to be agnostic about how storage is actually implemented.

Do you think it will be necessary / a good idea to write wrappers around storage functions?

[anonimal]

So, to cut down on refactoring, I was trying to think of a way to be agnostic about how storage is actually implemented.

That would be a good idea.

Do you think it will be necessary / a good idea to write wrappers around storage functions?

If you really want to hide the implementation, using the pimpl idiom could be helpful. In terms of interface, keep in mind the other uses of the database library (netdb for example).

[coneiric]

If you really want to hide the implementation, using the pimpl idiom could be helpful. In terms of interface, keep in mind the other uses of the database library (netdb for example).

Just read through some docs on pimpl [cppreference] [gotw_100].

Going to re-read (and re-re-read) the docs, and come up with a pimpl design for AddressStorage.
Will keep other uses and implementations (file, database, openldap) in mind.

[anonimal]

FYI, it's a 'compiler firewall' so it's not useful until we have a need to firewall. What could be useful for now is a generic storage interface which is abstracted from filesystem and db processing. That's not specific to this issue (#812) and should be opened in a new issue or commented in #385.

[anonimal]

NOTICE: THIS ISSUE HAS BEEN MOVED TO GitLab. Please continue the discussion there. See #1013 for details.