What about developping a SOAP/REST api with fasm in order to get some of the software market basics working with fasm, from the boot to the business.

others components comes after that, but actually, it seems the development is mainly based on this kind of interface, and connection is the keyfeature of any application.

Nowadays, the market is mainly dominated by java/c++ development just because of the presence of multiple "technologies" such as mongo, qt, wx, spring, swing, boost, and so many frameworks... causing the development process to be a full set of boring coding conventions and tools.

with fasm as a unique tool to build binaries and sources, it would be very funny to develop services, applications, systems and infrastructures.

just look at the new wave about microcontrollers, iot, android-x86, quark mcu, x86 phones, etc...

the idea is to build a workgroup and set a basic todo list in order to get a full fasm production toolset.

cheers

How far have you got with the code for this? Is this what your fool project will do? Are you intending to make a competitor protocol to SOAP/REST, or just implement the existing protocols in ASM?

implement protocols, give it a fasm stdcall/standard implementation to use in hll like c/c++, and of course, also in fool to implement for myself

for the moment, i am just nowhere, only the winsock2 socket part is working and is not ready for now. as i used libcurl/openssl and other boring struff for food, i realised fasm implementations would be very cool. the only "cool" lib to do the job would be a c++ boost set of templates... not so exiting.

1: the http protocol seems to be listen, connect, answer, respond, disconnect, listen.
2: everything is in the data exchange between client and server, headers, full url, forms, content.
3: the server should be able to handle as many clients as possible.

I made several tests with quetanon example and various networking applications to check how to do the job.

Do you know about the the library HeavyThing (from redsock)?

cool

Somewhat related, I am nearly done with the next release of the library, and I have decided to include my full DOM/XML/XHTML support (and I am fairly sure the fastest non-validating pull parser in existence) .. this could help with your SOAP requirements (namespace-aware XML handling is required for SOAP, notsomuch for REST, but the library already contains support for JSON handling)

I will try and push out the next version toward the end of this week