I'm rethinking how to approach the IDE topic. I'm OK with this not working out for lack of popularity. I just dont
want it to fail for not being done properly. So your feedback on how a
project like this should proceed is welcome, even if you aren't planning
to participate in the project itself.
It's entirely possible that "MV awareness" in both Sublime Text and VSCode will consist of many of the same features. It doesn't make a lot of sense to have two independent projects where people discuss these topics separately, reason out what we expect fromt these tools, logically prioritize, etc.
Aside from the programming languages used from the client IDE, the interface(s) to MV should be the same. That is, the pipes should generally be agnostic of the client, in a sort of MVC fashion. Implementation-specific details should be separate, but not at the cost of the valuable exchanges which are common to all IDEs.
I’ve expressed a preference to focus on one project at a time, for my own inability to spread too thinly across projects. But now I'm thinking that the definition of an IDE initiative is one project on its own, and there are separate projects for each IDE-specific implementation. Consider that in the real world we don't start with an implementation, we usually start with a spec. We generally create the RFC for a protocol before we implement a protocol. While independent innovation is valuable, some consistency is extremely helpful as people transition between implementations with expectancy of some basic common functionality.
It's not like there's a whole lot to do here - but I don't want to start off with a mis-configured project no matter the size.
So I'm looking for opinions on the following concepts:
- Start with a small project that just tries to define what we (a) expect and (b) want from IDE integration. For now I'll label this as the MvIdeRfc.
- Soon, but later, kick off a project for an mvIdeRfC implementation with Sublime Text.
- Soon, but later, kick off a project for an mvIdeRfC implementation with VSCode.
- Give the implementations a generic name so that others are not discouraged. In other words, the Sublime project might be called SaTurn and the VSCode project might be called VenuS. This way there isn't one dominating project called mvSublimeText.
- Encourage participation from those who have already published commercial offerings, like Pete Schellenbach with AccuTerm wED, and Doug Averch with XLR8. They've already been down the path and have a lot of experience to offer.
- There's no expectation that the RFC will conform to existing products.
- There's no expectation that existing products will conform to a new RFC.
- Each FOSS and commercial option should be equally available, with selection left to the consumer.
- Collaboration
- Google Groups is not well suited to hierarchical projects, sub-projects, etc. (there's no such thing here as a subgroup).
- A new Slack Team might be better for this, with channels for each project, where references are easier.
- Working documents can be provided in Google Docs.
- We could host code in GitHub but since the FOSS4MV repo already exists that might be a better choice.
Someone could say "in the time you take to talk about this I could have it done". Sure, but IMO that doesn't help others, doesn't provide any sort of centralization or consistency, and one-off projects like that will probably disappear into the nether like others before it. So for this specific area I suggest more organization would be much better.
I'm also trying to help get individuals in this industry to think more like an industry, like a community. We have no well-recognized FOSS hubs, no globally acknowledged forum. People have been wondering for years why "MV" doesn't take off (again?) and I believe that's in large part because the DBMS providers don't position themselves as "an industry" and individual developers as so stuck in the DIY mentality that the concept of collaboration is a strong anathema.
Thanks.
T