Hi, I am applying for the project Boost.XML. I have completed the competency test and the next step being proposal feedback from mentors, I have made a draft proposal. https://docs.google.com/document/d/1Bvno6ifHjo8EdMRuzFqCk9AEB5IgAxf2ag4xdc4Y... As this is a new library, I have not been able to add much in the 'Project Proposal' details except the bare minimum details. Mentors please have a look at it and let me know what you think. Should I make additions, remove or edit some things? -- Awaiting your feedback, Krushnal Patel http://krushnal.me/
Em qua., 17 de mar. de 2021 às 08:53, Krushnal Patel < krushnalpatel11@gmail.com> escreveu:
Hi,
Hi Krushnal, I am applying for the project Boost.XML. I have completed the competency
test and the next step being proposal feedback from mentors, I have made a draft proposal.
https://docs.google.com/document/d/1Bvno6ifHjo8EdMRuzFqCk9AEB5IgAxf2ag4xdc4Y...
Instead of creating several is*() functions, you could have a single function with a tokenType() member. Here are some examples of this approach: - https://github.com/breese/trial.protocol/blob/cd0055431ec42f30c53b295411ee00... - https://github.com/BoostGSoC14/boost.http/blob/fd8d6afb421ec58cbafe0a97f3df7... Could you use a page in your proposal to describe the user-supplied buffering mechanism? Write the mechanism with other users in mind. I'm already familiar with this topic, but if another user were to use your library, what's that he needs to know to write the glue between his application and your parser? I think that a well written tutorial for this section will show that you have a clear view of the steps involved from application-to-library. As this is a new library, I have not been able to add much in the 'Project
Proposal' details except the bare minimum details. Mentors please have a look at it and let me know what you think. Should I make additions, remove or edit some things?
The proposal is good already. If you want you could add one section describing problems in existing XML libraries. That's usually a good approach to share the vision you uniquely possess when you lay eyes on some problem. Regarding the timeline, I think this could be reworked. First one or two weeks should be used to prepare the infrastructure (e.g. Github CI + sanitizers). Unit tests should be developed as part of the library, not as an afterthought, so there is no need to reserve a special week on them. Also, I'd like to have a more detailed timeline. Could you break the timeline on a per-week basis? You could also add a spare week somewhere that we can use in case of delays (programmers are not good at time estimation, so having one spare week of “free time” is a good idea). -- Vinícius dos Santos Oliveira https://vinipsmaker.github.io/
participants (2)
-
Krushnal Patel
-
Vinícius dos Santos Oliveira