Task checklist (Features/TODO)

[Aniket21mathur]

Following is a possible task checklist for the library-

• Write basic plugin modules in C++ for generating chapel code. (Set up the project and add plugin modules with basic functionality #2 )
• Write scripts that set up the project. (Add setup script for the project #5 )
• Set up a testing architecture for the library. (Set up testing structure #10 )
• Add support for serialization to byte order for individual int32 and int64 fields.(Add support for serializing/deserializing int64 and int32 type #8 )
• Extend this support to have serialization and deserialization for an entire message or the Message type byte stream with key-value pairs.(Add support for serializing/deserializing int64 and int32 type #8 )
• Add channel implementation for serialize/unserialize methods(Add support for basic proto types #11 )
• Work on how to handle the package specifier in Chapel. (Add support for package specifier #13 )
• Add support for other proto field types- DOUBLE, FLOAT, UINT64, FIXED64, FIXED32, BOOL , STRING , BYTES, UINT32, SFIXED32, SFIXED64, SINT32, SINT64.(Add support for basic proto types #11 )
• Handle unknown fields (backward and forward compatibility) (Handle forward and backward compatibility #15 )
• Add support for repeated/reserved fields.(Support for Repeated fields and separate module for simple fields #14 )
• Add support for enums. (Add support for enums #20 )
• Add support for using message types as fields. (Add support for Message fields #22 )
• Add support for nested types. (Handle nested types #23 )
• Add support for the Any message type. (Support for any message type #33 )
• Add support for the Oneof field type.(Add support for oneofs #32 )
• Add support for Map. (Add support for Maps #24)
• Support JSON encoding.
• Add documentation for the project(Add user guide #16 , Add generated code guide #30 )
• Extend message types to support RPC system?
• Support for Reflection based operations

[lydia-duncan]

Add support for repeated/reserved fields.

Does this refer to optional vs required or is it something else entirely?

[lydia-duncan]

I think we'll also want to think about if we should generate both Chapel classes and Chapel records or if we should stick to just records (though definitely not right away). And also ways of supporting types that are unique to Chapel, such as ranges and domains (and how we'd specify array fields either way). Again, not an immediate thing to work on, just something to put on the list.

[Aniket21mathur]

Does this refer to optional vs required or is it something else entirely?

No, they are something different. The optional/required specifiers were removed in proto3, that's why I didn't add those to the list. You can see -> Why required and optional is removed in Protocol Buffers 3 😛

repeated allow us to repeat a message field any number of times.

reserved is used to reserve some field numeric values. From the official documentation ->

If you update an enum type by entirely removing an enum entry, or commenting it out, future users can reuse the numeric value when making their own updates to the type. This can cause severe issues if they later load old versions of the same .proto, including data corruption, privacy bugs, and so on. One way to make sure this doesn't happen is to specify that the numeric values (and/or names, which can also cause issues for JSON serialization) of your deleted entries are reserved. The protocol buffer compiler will complain if any future users try to use these identifiers. You can specify that your reserved numeric value range goes up to the maximum possible value using the max keyword.

We don't have to do much for reserved I guess, the protoc compiler will take care of it.

[lydia-duncan]

The optional/required specifiers were removed in proto3, that's why I didn't add those to the list.

Dang, they need to update their documentation page (or update the link that Google finds first)