Establishing an IDE project

[sprucely]

EugeneZ's recent post about his CodeProject article got me thinking about getting some collaboration going again.

I've been working on an IDE called Composer. I blogged about the idea some time ago at http://redspruce-blackspruce.blogspot.com/2012/02/composer-beginning-of-new-software.html. I currently have it in a private repository at bitbucket until I decide what license I want to release it under (probably MIT or BSD), but you can see a simple mockup of a component editor at http://redspruce-blackspruce.blogspot.com/2012/09/playing-with-d3js.html.

Composer has come a long way since then, but it still has a long way to go. It's a single-page web application. D3JS is used for manipulating svg elements. MVC and other patterns are implemented through use of AngularJS. Communication with an ASP.NET service is performed using SignalR. The database is Neo4j. The service communicates with the database via REST using Neo4jClient.

As far as implementation goes, it is currently possible to create single-connectors, multi-connectors and components. Cells can be added to components, and connections can be defined by holding down [ctrl] and dragging from one cell to another. Connectors and components can have tags specified, and a "Component Explorer" can be used to perform google-style searches on the tags (tag1 OR (tag2 AND (tag3 OR tag4))). Oh, and as an added bonus/coolness factor, a side affect of using SignalR means that component updates are broadcast in real time to all browsers that are viewing the given component.

What remains to be done includes differentiating between the various types of nodes as they are added to a component. Fleshing out the logic in determining what can connect to what. Implementing visual aspects of all the different types of cells. I still need to create a schema for managing data types and linking them to components. Oh, there is also no implementation of user management or authentication.

It was challenging switching from a SQL mindset to a graph db mindset. But I think it will be worth it, as the types of analyses on a COSA program, as described in Louis' postings, are where graph databases can really shine.

The interpreter will be called Conductor. I want to design it so that it can have multiple COSA data providers. One provider could efficiently pull component and data information from binary files. If useful, one could be made to connect to an XML representation of a COSA program. And an excruciatingly slow one could connect directly to the database.

So, is there interest? I'll provide anyone with access to the bitbucket project. Just give me your username. The project is somewhat large, as it includes Neo4j. I'm not sure if that was a good idea, but I wanted the project to build and run with minimal fuss. Any dependencies that aren't explicitly included will automatically be downloaded via NuGet at build time.

[sixwings]

Sprucely, I am happy to see that COSA is still percolating in your mind. Don't give up.

[EugeneZ]

EugeneZ's recent post about his CodeProject article...

Well... That is not even an article still. I just put some quotes and URLs to the web-sites about COSA. Sincerely, I have not yet described in English details about Logical Graph Assembler (I chose to name it like that), but I programmed a little piece of GUI in Java SE Swing. When I get my current affairs (Cisco exams) in order, I shall continue to work on it.

I plan to release it under GNU GPL v3.