|Posted by Bjoern||PermalinkReply|
From a very first view building a database model around *D* sources is as easy as Customer - Order - OrderDetail.
(Project - Package/Directory - Source)
Source revision could be implemented using db-journaling or a though db-triggers.(whatever you want, but depends on the DBMS)
Branches are more or less snapshots/views and even a ticket system is just another db-table. (in a bad designed db-model ;) )
This model (in fact a simplified model! ) is what I am using in my IDE.
A Question :
Is a D source file a UNIT ?
...at least when we do traditional source-code editing, Yes. Here even simple things (elements) like an email address, a http link are not handled by current systems.
Not good enough (tm)! Instead I imagine a Tool that is more flexible,: In no particular order; Builtins :A formula editor, visual module dependecies, visual code metrics, visual objects, Multi user support (collaboration).
builtin Prolog Engine. (Yes, instead of LISP) ++++
(Builtins should be designed as runtime loadable plugins).
Nothing new,so far: google for the Andrew GUI (if you like) native Oberon has such features for quit a while, there is a phd (i think) text too , called Text-Ing applications. (The Text-Ing stands for Text-engineering )
Okay, now finally :) to my question. How to serialze this stuff. In other words I have no idea how to store this kind of content into a RDBMS.
ORM seems to be a possible solution but I dunno. Maybe using something similar to CA's Jasmine DB ... Ideas ?
Next: Do YOU see a need for extending code editors functionality, or am I the only one ?
any Feedback is welcome, bjoern