You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The reason will be displayed to describe this comment to others. Learn more.
Durafront is basically a DuraLex server and Web interface. It can be discussed exactly what should be in DuraLex in a "main" entry point and what should be left to the users of DuraLex, I’ve no specific opinion on this, it’s just a matter of a dozen of lines there or elsewhere. Also, I wrote Durafront originally as a quick prototype for a Web interface of DuraLex/SedLex; now, given it works, the exact dispatching of roles could be improved by moving the lines; in particular, the "merge" operation coded here in Durafront (described in SedLex #1) could be moved to SedLex.
Beyond the exact dispaching of roles, I think the next big step is how we scale into a complete product: do we do an API? what specs exactly? how do we retrieve (or not) the data like amendments and law proposal? what diffs exactly do we provide, particularly do we chain DuraLex when the result is itself an amendment? do we do a specific web interface? and perhaps the more important: now that the whole pipeline works (for the average user), what promotion/communication/links with other projects do we do? (I will be in the Open Office the Fridays 18 and 25 January if you want/can come.)
cefe6bf
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't understand why you have some DuraLex code in another project.
The whole point of DuraLex is to generate a usable JSON.
cefe6bf
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Durafront is basically a DuraLex server and Web interface. It can be discussed exactly what should be in DuraLex in a "main" entry point and what should be left to the users of DuraLex, I’ve no specific opinion on this, it’s just a matter of a dozen of lines there or elsewhere. Also, I wrote Durafront originally as a quick prototype for a Web interface of DuraLex/SedLex; now, given it works, the exact dispatching of roles could be improved by moving the lines; in particular, the "merge" operation coded here in Durafront (described in SedLex #1) could be moved to SedLex.
Beyond the exact dispaching of roles, I think the next big step is how we scale into a complete product: do we do an API? what specs exactly? how do we retrieve (or not) the data like amendments and law proposal? what diffs exactly do we provide, particularly do we chain DuraLex when the result is itself an amendment? do we do a specific web interface? and perhaps the more important: now that the whole pipeline works (for the average user), what promotion/communication/links with other projects do we do? (I will be in the Open Office the Fridays 18 and 25 January if you want/can come.)