Re: Feedback on GSoC'21 project proposal

From: Vinícius dos Santos Oliveira (vini.ipsmaker_at_[hidden])
Date: 2021-03-19 17:43:03

Em qua., 17 de mar. de 2021 Ã s 08:53, Krushnal Patel <
krushnalpatel11_at_[hidden]> 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_aY/edit?usp=sharing
>

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/cd0055431ec42f30c53b295411ee00cade8b9b5e/include/trial/protocol/json/reader.hpp#L88
   -
   https://github.com/BoostGSoC14/boost.http/blob/fd8d6afb421ec58cbafe0a97f3df709bcf8ed723/include/boost/http/reader/request.hpp#L50

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/