Skip to content

HTTP Client POC#20

Open
erno-szabados wants to merge 84 commits intorsdoiel:mainfrom
erno-szabados:feature/Http
Open

HTTP Client POC#20
erno-szabados wants to merge 84 commits intorsdoiel:mainfrom
erno-szabados:feature/Http

Conversation

@erno-szabados
Copy link
Copy Markdown
Contributor

Overview

The goal here is to implement a proof of concept HTTP Client. It works with a simple local python client but not in a real setting (could not handle connection keepalive, for example).

I thought this is a good real world task to validate implemented functions.

Sorry for the big change set, I think there's a lot of useful code. I got bored with the details in the end but wanted to provide it anyway. It could either go to main or to its own feature branch if you find it valuable.

I've found that the mixed use of oberon strings and dstrings is cumbersome, maybe the logger (and other modules) could use extensions to handle dstrings. Deciding what part should rely on the oakwood modules or the new modules was difficult. I think more thought should be given to this, if anyone would like to use this API, as priorities would be different for embedded or lightweight systems and for linux command line tools, just to name a few.

Features

  • Implemented a tokenizer, parser, http header request response processing and a client on top of it.

Bug Fixes

  • I've found some issues with the socket wrapper, a semantic issue and a bug in DString.

  • Fixed an off-by-one error in DStrings.Mod's TrimLeft procedure and corrected logic in WriteDString to ensure proper string operations. [1] [2]

  • Corrected a typo in the documentation comment of WriteFixed in DStrings.Mod.

Code Simplifications

  • Simplified the Dictionary.Mod by removing unnecessary intermediate variables (dictState) in adapter procedures and directly accessing the visitor state. [1] [2]

Copilot Updates

  • Updated .github/copilot-instructions.md I used github copilot, but the assistance it could provide for a niche language like oberon-07 is limited. Thus the very detailed copilot guidelines.
  • Movedd C wrapper creation instructions to a new file .github/instructions/CreateOberonCWrapper.instructions.md.
  • Added .github/instructions/NewOberonModuleCreationOBNC.instructions.md to provide detailed steps and best practices for creating Oberon modules using the OBNC compiler.

…ragment types; add initial test suite for HttpUrl module.
…add comprehensive tests for full URL parsing.
…roved string handling and memory management.
…tation; update index.html to include new modules
… and add helper functions for better readability and maintainability
…ndling, including body parsing and logging. Update tests to reflect changes in response parsing methods.
… management. Ensure accumulated data is returned if delimiter is not found before socket closure.
…er handling. Enhance logging for socket errors and streamline data extraction logic.
…ing the loop. Retain partial data for subsequent calls if the loop exits due to WouldBlock or Closed.
…t closure without Content-Length. Implement max byte limit and improve error handling.
@rsdoiel rsdoiel self-assigned this Jul 21, 2025
@rsdoiel
Copy link
Copy Markdown
Owner

rsdoiel commented Jul 21, 2025

This is interesting. I need to think about this one. I'm OK with wrapping C libraries (I understand how to do that with OBNC) but adding Python into the mix seems to make things more complex (perhaps I miss reading your description?).

On my some day maybe list is some sort of generic map/dict like object that can be used in the web context and for mapping data in from structured data formats like JSON or YAML. For my own project interest this would make Oberon-07 a more attractive option.

That said being able to spin up an HTTP client also seems really intriguing. Anyhow, let me think on this a bit. Thank you for the submissions. It has encouraged me to get back to this project when I can squeeze some time for it.

@erno-szabados
Copy link
Copy Markdown
Contributor Author

Thanks for taking a look at this pull request.

The python code is there for testing the http client only. It is not needed for the client, but as the current http client implementation could not handle the complexities of real world http I wanted to provide something for verification, as this could not be really tested in isolation.

It could be moved to a separate folder maybe, or we could remove it altogether and just leave instructions in the readme or the module source.

As for json and xml these would require either wrapping a c library (jsonc is promising for json, did not research xml in depth in this regard) or for a portable oberon solution write tokenizer, parser, etc. these are more involved tasks, where multiple layers must be designed and implemented l.

And for pure http client functionality, wrapping libcurl would be also viable and would enable some use cases (I was thinking about doing this, but I was curious about how usable Oberon would be to do this from scratch.

Going on with such decisions would require more strategic planning - what use cases should Artemis enable or support - embedded systems? Small games and tinkering on minimal systems? Writing generic tooling somewhat similar to what go is used for?

@rsdoiel
Copy link
Copy Markdown
Owner

rsdoiel commented Jul 23, 2025 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants