Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add typing to serialization scheme #113

Closed
LivInTheLookingGlass opened this issue Nov 16, 2016 · 6 comments
Closed

Add typing to serialization scheme #113

LivInTheLookingGlass opened this issue Nov 16, 2016 · 6 comments

Comments

@LivInTheLookingGlass
Copy link
Collaborator

So the new structure would be like:

Header
Size of packet 0
Type of packet 0
Packet 0
Size of packet 1
Type of packet 1
Packet 1
...
@LivInTheLookingGlass
Copy link
Collaborator Author

This is a continuation of #100

@LivInTheLookingGlass
Copy link
Collaborator Author

The idea would be to modify the InternalMessage.__process_string method to use specific constructors. So it would look instead like:

    def construct_value(data, flag):
        if flag in (flags.uint, flags.ulong):
            return unpack_value(data)
        elif flag in (flags.int, flags.long):
            ret = unpack_value(data)
            if ret & 2**(len(data) * 8 - 1):
                return -(ret ^ 2**(len(data) * 8 - 1))
            return ret
        elif flag == flags.str:
            return data.decode()
        else:
            return data


    @classmethod
    def __process_string(cls, string):
        processed = 0
        packets = []
        while processed < len(string):
            pack_len = unpack_value(string[processed:processed+4])
            pack_type = string[processed+4]
            processed += 5
            end = processed + pack_len
            packets.append(
                construct_value(string[processed:end]), pack_type)
            processed = end
        return packets

This obviously doesn't include the real restrictions on int and long sizes, nor do I really know how to make this work in C-like languages very conveniently.

@LivInTheLookingGlass
Copy link
Collaborator Author

Keeping buffer as the default behavior does prevent someone's bad implementation from ruining things, however.

@LivInTheLookingGlass
Copy link
Collaborator Author

As a note, this should not be implemented until a graceful solution in C can be found. The CPython API is a good place to look, but it's certainly not pretty.

@LivInTheLookingGlass
Copy link
Collaborator Author

@micaiahparker

This seems like something you might be interested in.

@LivInTheLookingGlass
Copy link
Collaborator Author

Here's a thought for dealing with this. What if everything is treatable as a buffer, unless you check it's type? I don't know how this would work in python, quite yet, but in C it would look like:

uint32_t example(struct InternalMessageStruct *msg) {
    if (InternalMessagePayload_is_uint32(msg, 0)) {
        return InternalMessageGetPayload_uint32(msg, 0);
    }
    return -1;
}

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

No branches or pull requests

1 participant