search

bitmark-inc / spring

SPRING: Your Facebook Escape Hatch.
2 stars 0 forks source link

API to get parser version #38

Open jollyjoker992 opened 4 years ago

jollyjoker992 commented 4 years ago

To issue archive that has been parsed successfully to Bitmark blockchain, we need the parser version to include into archive information and add it as metadata for the issuance. If archive is parsed successfully, it should be include the parser version and expose the way to get it.

jollyjoker992 commented 4 years ago

@lemonlatte Hi Jim. We have a task in this sprint related to this request. Could you help to do it by next Monday or Tuesday? We need time to implement and check it.

lemonlatte commented 4 years ago

I think I could not help before I understand what is going on here. Do you have design, document or story I can reference to?

lemonlatte commented 4 years ago

Reference to https://github.com/bitmark-inc/fbm-apps/issues/27

jollyjoker992 commented 4 years ago

@lemonlatte Referenced issue is here. In my mind, i think it would be better if we return the parser version along with the archive status when Spring server polling from. It will be the same if we migrate to webhook later (currently we have to polling periodically)

lemonlatte commented 4 years ago

I do not understand the polling part. Could you just hard coded the parser version with 0.0.1 at the moment you want to bitmark for now? Codes are all put together in the API server. People might update the parser without proper version it.

jollyjoker992 commented 4 years ago

@lemonlatte

Could you just hard coded the parser version with 0.0.1 at the moment you want to bitmark for now?

I'm not sure @moskovich will agree with that.

I do not understand the polling part

Currently Spring server has to polling to DT42 server to get the archive status after it has been uploaded successfully. We already designed the webhook but seems like DT42 prefer to polling first for some internal reason from them. Client app will get archive status from Spring server (and it would be better if the response contains parser version) to determine whether the archive is processed.

lemonlatte commented 4 years ago

Currently Spring server has to polling to DT42 server to get the archive status after it has been uploaded successfully. We already designed the webhook but seems like DT42 prefer to polling first for some internal reason from them. Client app will get archive status from Spring server (and it would be better if the response contains parser version) to determine whether the archive is processed.

@jollyjoker992 Please open a new issue to pushing the webhook mechanism. Or if you have already created the issue and no one see or response it, please send it to me. I will work out a way to work with them and solve it.

tammyyang commented 4 years ago

@lemonlatte

Could you just hard coded the parser version with 0.0.1 at the moment you want to bitmark for now?

I'm not sure @moskovich will agree with that.

I do not understand the polling part

Currently Spring server has to polling to DT42 server to get the archive status after it has been uploaded successfully. We already designed the webhook but seems like DT42 prefer to polling first for some internal reason from them. Client app will get archive status from Spring server (and it would be better if the response contains parser version) to determine whether the archive is processed.

@jollyjoker992 just to clarify, there is no preference or internal reason at Numbers to poll data. As far as I can remember, this choice was only because the time limitation so that the both side (App and Data Processor) choose to poll data for the first demo launch.

jollyjoker992 commented 4 years ago

@tammyyang Yes, I know. Just to generally summarize for Jim. Thank you.