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
The Document Service is the single most difficult component of Proxeus for us to maintained. It is written in a different programming language (Java), and has a cumbersome solution architecture which is typical of "rapid prototyping" at startups. I would like to try to decouple it from proxeus-core, first of all by making it possible to start Proxeus with all document features (template previews, PDF generation) disabled.
As a second step, to research alternatives - both for improving the software architecture (NextCloud libraries instead of LibreOffice instantiation) as well as cloud solutions (reports-as-a-service). We briefly discussed whether it could be possible to turn Document Service into a Node, from a usability perspective. This led to the idea of using easily supported XML transformations to inject form data into open formats like ODT and SVG, and leveraging the frontend (e.g. via PDF.js) for further steps in document generation.
Finally, as we realized that we probably lack the skills in the team to do this fully, we would work on a prototype and draft an RFP, then recruit another developer with some specialty in this area to finish the job.
2. Alt-chains
S-Pro has been pursuing ~Project: Polygon and support for other Ethereum ~Tech: Alt-Chain and will focus the rest of their sprint on finishing this project. We should soon have a feature release that allows to comfortably continue using Proxeus with modern blockchains.
Having a clear interest in being a part of the blockchain ecosystem, we should approach the network for a grant that would enable further development and integration work, for example to develop Proxeus Nodes compatible with automations or cloud services of interest.
There was some discussion of having a set of "demo keys" for Infura (and Sendgrid) to ease developer entry into the project. We decided to just prepare a text file with instructions and distribute it internally (e.g. via this Mattermost).
The team understands that the idea of a Proxeus hackathon would be a good format to co-develop in this direction, and we will look for some dates in the spring, discuss this with S-Pro management and potential sponsors.
3. Microservices
We had some discussion around the monolithic architecture of proxeus-core, and what benefits there would be to potentially decouple the whole frontend more. Project Tango already demonstrated an interesting desktop-based interface to Proxeus, and we could easily imagine Wordpress plugins or other widgets that could interact with Proxeus services through an API.
Recently I've been even wondering what a console-level (CLI) interface to Proxeus might look like, and read through the workflow tests to see how the API interactions could be mapped to commands. It's at least a good thought exercise 🙂
Proxeus already has a separate "Developer" and "User" frontend, but we have not yet tried embedding the signing and validation of certifications into external projects. This would be quite interesting from a business perspective, and should be given some priority.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Notes from discussion today with the maintainers:
1. Document service
The Document Service is the single most difficult component of Proxeus for us to maintained. It is written in a different programming language (Java), and has a cumbersome solution architecture which is typical of "rapid prototyping" at startups. I would like to try to decouple it from proxeus-core, first of all by making it possible to start Proxeus with all document features (template previews, PDF generation) disabled.
As a second step, to research alternatives - both for improving the software architecture (NextCloud libraries instead of LibreOffice instantiation) as well as cloud solutions (reports-as-a-service). We briefly discussed whether it could be possible to turn Document Service into a Node, from a usability perspective. This led to the idea of using easily supported XML transformations to inject form data into open formats like ODT and SVG, and leveraging the frontend (e.g. via PDF.js) for further steps in document generation.
Finally, as we realized that we probably lack the skills in the team to do this fully, we would work on a prototype and draft an RFP, then recruit another developer with some specialty in this area to finish the job.
2. Alt-chains
S-Pro has been pursuing ~Project: Polygon and support for other Ethereum ~Tech: Alt-Chain and will focus the rest of their sprint on finishing this project. We should soon have a feature release that allows to comfortably continue using Proxeus with modern blockchains.
Having a clear interest in being a part of the blockchain ecosystem, we should approach the network for a grant that would enable further development and integration work, for example to develop Proxeus Nodes compatible with automations or cloud services of interest.
There was some discussion of having a set of "demo keys" for Infura (and Sendgrid) to ease developer entry into the project. We decided to just prepare a text file with instructions and distribute it internally (e.g. via this Mattermost).
The team understands that the idea of a Proxeus hackathon would be a good format to co-develop in this direction, and we will look for some dates in the spring, discuss this with S-Pro management and potential sponsors.
3. Microservices
We had some discussion around the monolithic architecture of proxeus-core, and what benefits there would be to potentially decouple the whole frontend more. Project Tango already demonstrated an interesting desktop-based interface to Proxeus, and we could easily imagine Wordpress plugins or other widgets that could interact with Proxeus services through an API.
Recently I've been even wondering what a console-level (CLI) interface to Proxeus might look like, and read through the workflow tests to see how the API interactions could be mapped to commands. It's at least a good thought exercise 🙂
Proxeus already has a separate "Developer" and "User" frontend, but we have not yet tried embedding the signing and validation of certifications into external projects. This would be quite interesting from a business perspective, and should be given some priority.
Beta Was this translation helpful? Give feedback.
All reactions