Regex UCR: Plans forward — architecture and licensing first steps
Part 4
Regex You Can Read: How It Works presented the why and what of Regex UCR design. Now it’s time to look at how we are gonna go about creating actual software.
What we’ll need next
(Updated Sept 9, 2016) This is a GPL’d open source project. My wish is to give out plenty of responsibility to people who share enthusiasm for something like what’s presented above. Below, I present specific areas of responsibility that I would love you to take over, but there is still plenty of room for you to carve out the role that works for you exactly.
Regex UCR will primarily be a web app. In the long term, the goal is to have an IDE plugin as well.
We already have a simple non-functional React UI by Byron Houwens. I am dreaming of TypeScript both client and server side, but this decision really depends on the team makeup and what the key players are comfortable with.
We would like as much of this as possible to run in the browser, to see how much of this can work also in offline mode (and perhaps also be embedded as an IDE plugin, for example). We can likely do the lexing and parsing client side. For debugging, I think we will need a cloud server that can actually run all/most of the various regex engines. That part can parhaps also be a premium/paid service.
We’ll also need is a data structure — a dictionary of some kind — for this reasoning. It will contain data about the dialects and their corresponding symbols in the visual notation.
Also, though not strictly necessary for the MVP (minimum viable product), we will need the contextual data for the menu, possibly in another data structure. When we are inside structure X, prioritize elements S in the menu.
Of course we also need the actual UI presentation. In current plans, React and d3 will likely help us here, allowing us to sync the regex and the visual UIs, and to render the visual syntax, along with the cursor and the menu.
Plans forward: Modular architecture
The aim is to have a plugin architecture built in. As I see it now, there will, in time, be several parts of the UI that are suitable to be implemented as Core Plugins.
These will be described in future posts, and include:
- Element description panel (prototype championed by Byron Houwens)
- Regex testing/debug panel
- Element insertion panel (idea pioneered by Sam Sullivan)
All the dialects will be pluggable as well, as new ones come and go. We will eventually need a dialect definition format that allows defining elements and linking them to elements of other dialects. You may also have noticed that switching between different regex dialects is not trivial in some situations. This is covered in Regex You Can Read: Generating different Regex dialects.
Our current skeleton of a minimal viable product is built using React. Help with breaking down work into manageable tasks is appreciated to be able to estimate the amount of work that the minimal viable product will require.
working to map out importer/exporter classes for a base dialect, like PCRE.
— Then, we could take those classes and build a set of terms that relate to different sets of our dialect’s definitions. This could be searched very quickly on the backend with something like Elasticsearch…I think we could make this have an acceptable latency for a web app. -Sam SullivanThe vision is one of a web app that can work in offline mode, at least to a limited extent. When in online mode, I would very much like to leverage technology that enables collaboration for this, i.e. something like Meteor’s syncing capabilities.
There will also be mouse and touch compatible UI with an element palette and right click menus. We have agreed for now though that getting the keyboard interaction is first priority.
Licensing
We need doers and shakers. Developers, and crowdfunding experts, please join us. I am not in this for the money — I just believe the quiet majority of users needs someone to champion their point of view in the regex community. I want to work as collaboratively as is humanely possible. Good design rarely happens by committee, but I welcome fair and open discussion and debate at any point.
I am here to share and discuss, and to find a financial model that makes this viable. I will be spearheading creating a crowdfunding campaign. We will create a fair model together on how to share the income and make this happen.
The service will be paid/freemium with added features. The source of the product will be open and free for users but it seems reasonable to incentivize IDE developers to pay license fees, by using a license such as GPL.
That said, our first priority is making it actually publicly available as a reliable online service.
I’d be hard pressed to think of this as a purely commercial/closed source product, but I will hear your argumentation, and if you think that’s what it takes to get this into people’s hands, I am prepared to reconsider.
The funding will roughly be used as follows.
- Maintenance cost of the service, i.e. infrastructure costs.
- Fair, contribution based compensation for designers and developers working on the product.
- Buffer fund to make sure we can prepare for future challenges and product development needs.
Your thoughts?
Contact me to join our Slack channel so we can work together on this. Our github repository is also now open. So far we have a React-based skeleton UI built. We warmly welcome any help bridging the gap from design to code.
