Hi Fabian - Thank you for your interest in CodeDB2 and all the praise even though development has just started ;-).
1) Do you have any plans yet for doing distributed development with that (distributed as in several deployments)? On a single site, I expect the workflow to be similar to the one in ENVY/Developer. Yes, we do have plans for distributed development. We never really oriented on ENVY/Developer but after reading those ideas, some are similar to what we have in mind. Maybe this answer will be to technically but basically we want to change our numeric version numbers to hashed the way they are used in GIT. Doing this should make distributed development possible. We also want to use CouchDB replication as good as possible, meaning that synchronization should be easy and with fine-granular "code objects"** there should be less need of merging/manual conflict resolution. 2) Will there be a package format and if so, how can these be shared? Right now we did not think of explicit packages, however we will have change sets and modules (in a way similar concepts) that will be shared. Then, I saw that you, Marko, put a description of document schemas in the wiki (http://lively-kernel.org/repository/webwerkstatt/projects/CodeDB2/info_documents.xhtml). For a feature-list rather have a look at http://www.lively-kernel.org/repository/webwerkstatt/projects/CodeDB2/contents.xhtml. It feels a little bit like we are moving towards "the second version syndrome" but as lets see what will make it into CodeDB2 and what will be CodeDB3 ;-). (I also consider CodeDB(1) to be a POC from our perspective right now...) Now these schemas look structured enough to save them in a relational database. I'm not indicating that this is a great idea, but you can guess what company might be interested in that. [...] I'm wondering if you could easily put those objects into an RDBMS (trivially, you could, but you sort of want to preserve the schema in that case). Well, it definitely is not :-p but those schemas are very "unstable" right now. There are still a lot of changes but we try to keep this document up-to-date. What makes CouchDB (as database) so unique is that it is application server and database in one. So "obvious parts" of a world/part/module file can be omitted and Javascript/XHTML files can be created "on-the-fly" using CouchDB's Shows and Lists (http://wiki.apache.org/couchdb/Formatting_with_Show_and_List) while writing changes/code to the database really just contains the "clean" code. But a Node.JS server might to the same after querying a RDBMS... 3) does CodeDB run completely inside CouchDB, and if so, what will the interface look like? You'd probably POST these code entities to some RESTful route (rather than posting complete files)? You are putting/deleting/reading CouchDB documents via its RESTful api to manage "code objects"**. When accessing modules, worlds, etc. for execution/loading, shows and lists will generate code that can be interpreted directly by a browser (meaning a well-formed Javascript file or (X)HTML page). Currently also the url patterns are still changing but rewriting will hopefully make everything look like the filesystem structure we have right now. I hope this will give you a feeling of what is to come :-). - Marko ** code objects are small units of source code. This can be a method, a class definition, a module description, etc.
_______________________________________________ lively-kernel mailing list [email protected] http://lists.hpi.uni-potsdam.de/listinfo/lively-kernel
