achakravarti / argent Goto Github PK

The test cases for the logging interface need to be prepared.

The compiler extensions that are developed as part of #8 need to be documented.

We need a means to log information at runtime. The logging mechanism provides an interface for adding log messages of varying severity. Ideally, the logging mechanism would be a wrapper around the syslog facility.

The test cases for the string interface need to be prepared.

Probably the most important feature of the Argent Library is its ability to handle the FastCGI protocol. We need a wrapper around the libfcgi API in order to simplify the handling of HTTP requests through FastCGI.

Generating the JSON representation of an object may be useful in some cases, and so it makes sense to have an ag_object_json() method.

Association lists (a-lists) are lightweight singly linked lists containing key-value pairs, and are useful in situations where there are only a few such key-value pair mappings.

Experience has shown that it is useful to incorporate reference counting directly into the memory block interface. This would simplify the implementation of string and object interfaces. The only caveat is the extra size_t bytes that are padded into each memory block. However, nearly every type that relies on dynamic memory would be satisfied by either an object or a string, this is an acceptable compromise.

Accordingly, we are revising the existing interface with the following functions:

• ag_mblock_new()
• ag_mblock_new_align()
• ag_mblock_copy()
• ag_mblock_retain()
• ag_mblock_release()
• ag_mblock_dispose()
• ag_mblock_cmp()
• ag_mblock_lt()
• ag_mblock_eq()
• ag_mblock_gt()
• ag_mblock_sz()
• ag_mblock_refc()
• ag_mblock_alignment()
• ag_mblock_resize()
• ag_mblock_str()

We are choosing _mblock_ identifiers in order to avoid namespace collisions with the existing _memblock_ identifiers. The ag_mblock_retain(), ag_mblock_release() and ag_mblock_refc() functions are specifically related to reference counting.

References:

• https://stackoverflow.com/questions/1898153/

While attempting to run a client application using the Argent Library, bugs are being detected in the HTTP subsystem. These need to be fixed as they are being detected.

• ag_http_request *ag_http_request_new(enum ag_http_method, enum ag_http_mime, const ag_http_url *, const ag_http_client *, const char *);

• enum ag_http_mime ag_http_request_mime(const ag_http_request *);

• enum ag_http_method ag_http_request_method(const ag_http_request *);

• ag_http_client *ag_http_request_client(const ag_http_request *);

• ag_http_url *ag_http_request_url(const ag_http_request *);

• ag_alist *ag_http_request_param(const ag_http_request *);

• ag_http_url *ag_http_url_empty(void);

• ag_http_url *ag_http_url_parse(const char *);

• https://stackoverflow.com/questions/726122/

• https://stackoverflow.com/questions/417142/

• https://stackoverflow.com/questions/14402407/

• https://webmasters.stackexchange.com/questions/16996/

• https://www.xspdf.com/resolution/20036994.html

Also explore removing object registry and typeid

Experience has shown that having an object system is a very useful abstraction. The object system provides a reference counted object model that implements a simple copy on write mechanism for improving copy performance.

Now that the new memory block interface (with in-built reference counting support) is in place, we need to rewrite the existing string interface to use the former.

A dynamic type system supporting both primitive types and ag_object_t instances would be very helpful in creating generic containers. The type system would be inspired by the one implemented in JavaScript.

Now that we have improved memory block and string interfaces in place, we can take the next step of rewriting the existing object interface with the new code. We should also consider adding a valid() function to the object interface to indicate whether or not it is in a valid state. This may be particularly useful in the case of business objects.

Documentation is an important part of this project, and I would like to explore the ideas that I have developed while working on the Live After 60 project. Although many documentation generators exist such as Doxygen, I have opted to use LaTeX owing to a rich feature set provided by it in addition to the flexibility and rigour that it entails.

In this issue, we need to create the general layout of the documentation, and the Makefile build target to generate the same.

The detailed documentation of the memory pool interface needs to be prepared.

The logging interface needs to be documented.

Currently, every object has its own copy a struct ag_object_vtable. This makes objects relatively bulky. We can trim down the fat by sharing the struct among all objects of the same type. To do so, we need to introduce a type field to the object against which it can perform a lookup in the object v-table hash table.

The test cases for the runtime checks interface needs to be prepared.

Runtime checks through assertions and a simplified exception handling system need to be introduced.

Although I don't follow a TDD approach, ensuring high coverage in testing is of prime importance. Although there are several testing frameworks available, I prefer to use a hand-rolled testing system that just fits in with the project workflow and keeps things comparatively simple.

The existing exception handling interface is usable, but experience has shown that it is a bit clunky and that there is room for improvement. The main improvement comes through creating a list that holds the exception handlers. This helps make both the existing exception handling interface and the client code depending on it cleaner.

Accordingly, we would revise the interface as follows:

  - ag_erno;
  - ag_exception_handler(erno, func, file, ln, void *);
  - ag_exception_init();
  - ag_exception_exit();
  - ag_exception_register(erno, msg, hnd);
  - ag_exception_msg(erno);
  - ag_exception_hnd(erno);
  - ag_assert();
  - ag_require();
  - ag_require_opt();

Now that we have the memory block, string and object interfaces rewritten, we are in a position to rewrite the value interface to use the new interfaces.

• backtrace()
• backtrace_symbols()

Supported both on GNU/Linux and FreeBSD. Threads supported.

• typedef void ag_dso;
• ag_dso *ag_dso_load(const char *path);
• void *ag_dso_sym(ag_dso *ctx, const char *sym);
• void ag_dso_unload(ag_dso **ctx);

• ag_http_client *ag_http_client_new(const char *ip, const char *port, const char *host, const char *agent, const char *referer);
• ag_string *ag_http_client_ip(const ag_http_client *ctx);
• ag_uint ag_http_port(const ag_http_client *ctx);
• ag_string *ag_http_host(const ag_http_client *ctx);
• ag_string *ag_http_client_agent(const ag_http_client *ctx);
• ag_string *ag_http_client_referer(const ag_http_client *ctx); [sic]

The memory pool interface currently does not support the allocation of memory blocks aligned to certain offsets. We need this mechanism to allow the portable tagging of pointers for the dynamic type system.

Refer to https://stackoverflow.com/questions/227897/.

The string interface needs to be documented.

It would be nice to have continuous integration with Travis CI incorporated into the Argent Library.

Heap memory management is essential, and I hope to eventually develop a memory pool system for use with this project. However, for now, the memory pool interface would simply be a wrapper around the standard malloc(), realloc() and free() calls.

• Manage FastCGI calls
• Manage HTTP request plugins/callbacks
• typedef void (*ag_http_handler)(const ag_http_request *req);
• void ag_http_server_init(void);
• void ag_http_server_exit(void);
• void ag_http_server_register(const char *path, const char *dso, const char *hnd);
• void ag_http_server_run(void);

The test cases for the memory pool interface need to be prepared.

Edit: The memory pool interface has been deprecated in favour of the ag_memblock_t interface.

Experience has shown that a few of the extensions provided by GCC are quite useful. Wrapping them around macros provides a clean way to degrade them on compilers that do not support the GCC extensions.

• ag_http_url *ag_http_url_new(bool secure, const char *host, const char *port, const char *path);
• bool ag_http_url_secure(const ag_http_url *ctx);
• ag_string *ag_http_url_host(const ag_http_url *ctx);
• ag_int ag_http_url_port(const ag_http_url *ctx);
• ag_string *ag_http_url_path(const ag_http_url *ctx);

The object model interface needs to be documented.

Strings play a pivotal role in this project as they are used for exchanging data between the database, application and user interface layers. Since there is potentially a lot of copying of string instances involved, it would seem to be a good approach to implement them as a specialisation of the object model.

One of the benefits of having an object model is that we can create generic data structures. We need a singly linked list container for objects for situations where the number of nodes is few and the performance penalty for sequential access is acceptable.

Regular expressions would be extremely useful in the validation of user input.

The test cases for the object model interface need to be prepared.

The runtime checks interface needs to be documented.

• Introduce enum AG_LOG_LEVEL
• Replace current functions with single ag_log_write()
• Keep possibility of introducing ag_log_read()