-
Notifications
You must be signed in to change notification settings - Fork 16
/
Copy pathTODO
103 lines (70 loc) · 3.49 KB
/
TODO
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
high priority
=============
Fix generated code so that unknown proto fields are collected into a data
structure.
Remove all references to the BASE package in generated code. Make generated
files independently loadable.
Use base::vector-index or eliminate it in protobuf Lisp files?
Add more tests for merging from a protobuf instance.
Implement extensions
Add tests
Look at all XXXX comments in the compiler source and remove them.
involves filing some bugs against C++ code
General stuff
=============
5. read the binary description of a protocol buffer into RAM
output S-expression protobuf forms
Compare output to S-expression backend of compiler on all Google protobufs.
Talk to Kenton about which approach he prefers -- backend or binary reader.
6. read S-expression protobuf forms
create internal protobuf data structures that represent the messages
generate Lisp code that uses proto form to read and write binary data
generate Lisp code that directly reads and writes binary data
Look at the Java unit tests for unittest.proto
Maybe the Java semantics are what we want, since protos are more
immutable in the Java world.
What do we do with strings?
Some are declared as byte(octet) arrays, others as strings.
add slick check-several bits code to clear / is-initialized
implement RPC service stubs ??
protobuf
========
move more unit test code from google-protobuf/src/google/protobuf into protobuf
review proto-lisp-test code ... remove it ?
move the package decl for protocol-buffer into each compiled file?
would be nice of users could just load a compiled protobuf
pick a testing framework
Port the tests to the unit test framework.
look at all tests in google-protobuf/src/google/protobuf
start migrating them here
create a testing directory?
Figure out a strategy for specifying Common Lisp optimization levels and
apply it uniformally. There's some support for this in optimize.lisp, and
there are some #+opt conditionalizations sprinkled around the code.
google-protobuf
===============
add extensions and other features needed to load protobuf files
add README file to the top level explaining the Lisp changes
merge in latest Google changes
other
=====
Implement a protocol buffer compiler. There are several ways to do this.
Here are my favorites:
a. Implement a new backend for Google's protocol buffer compiler that
generates CLOS classes from protobuf descriptions. It is unlikely that
Google will integrate this change into their code, and it requires Lisp
developers to use Google's protobuf syntax.
b. Implement a new backend for Google's protocol buffer compiler that
outputs protobuf descriptions in s-expression form. Write a compiler in
Lisp that translates the s-expressions into CLOS classes. Google may be
more receptive to integrating this change into their code, since it is
useful for any language in the Lisp family. Also, the change is much
smaller, amounting to just a pretty printer. Lisp developers can write
protobuf descriptions as s-expressions. The disadvantage is that this
approach is a bit more work.
c. Implement a compiler via either of the methods above that converts
protobuf descriptions into run-time data structures. The programmer
decides which protobufs are translated into code at compile time and which
are translated at run time. In the second case, the CLOS generic
functions for a protobuf would just be small stubs. When they are ever
called, they replace themselves with the right access code.