CodeDB plans?
Locked
 
|
Hi,
Marko, Lauritz and I wanted to skype about CodeDB earlier this week, but why not let everyone participate in this discussion ... so here we go. I have a couple of questions beyond "what's the progress", especially regarding version control. 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. 2) Will there be a package format and if so, how can these 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). I think that gives us an idea about where this is going, and I think it's awesome. 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. Hence my question is 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)? 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). As I said, I'm very excited about this. Cheers, f _______________________________________________ lively-kernel mailing list [hidden email] http://lists.hpi.uni-potsdam.de/listinfo/lively-kernel |
|
|
Folks -
It's great to have our discussions back in the mail list, and especially to see some outside interest. I think it's going to be an awesome autumn! Now that we are focusing a bit more on social enablement of our project, I have an idea for an artifact that might enhance everyone's spirit of participation. It's... * THE LIVELY DASHBOARD * We already have a number of useful and almost-useful tools for viewing the progress of our community. I think it would be really exciting to assemble these all on a single page. Consider the following assembled gestalt: Recent events (eg, a list of recent talks or other presentations, with dates) Other related news (public mention of Lively, or things like the Dart announcement) Tweets or Facebook mentions of note Bug reports, posted and fixed Feature requests, posted and done All recent system changes All recent wiki changes New subscribers to mail list / also unsubscribers Changes to Lively communities on Facebook, Twitter, etc. Personal status, as in "working on Git port" "building a Lively Dashboard", etc (These might no be needed if the rest works well enough) New (or improved) apps or other fun things in the parts bin(s) Active projects list (links to project pages) [If these are sorted by write date, it would motivate us to update project pages whenever we make progress] I'm imagining that many of these are scrollable time-sorted lists so you only see the most recent activity, but it's easy to explore more right there. Also I'm imagining that items from the last day or two might be highlighted in color. I also can't imagine it without some cool live graphic that gets changed from time to time. Whaddya think? - D _______________________________________________ lively-kernel mailing list [hidden email] http://lists.hpi.uni-potsdam.de/listinfo/lively-kernel |
|
|
In reply to this post by Fabian Bornhofen-2
Hi Fabian - Thank you for your interest in CodeDB2 and all the praise even though development has just started ;-).
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.
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.
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...)
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...
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 [hidden email] http://lists.hpi.uni-potsdam.de/listinfo/lively-kernel |
|
|
Besides that, storing a JSON serialization (worlds, parts) in a JSON-based (document-oriented) database makes it possible to do some analysis on those serialization (very easy with CouchDB), e.g. local code "extraction", reference/usage counting, ... I still believe CouchDB has some extraordinary features that make it the right database (if any at all) to put source code/the Lively Kernel in. - Marko _______________________________________________ lively-kernel mailing list [hidden email] http://lists.hpi.uni-potsdam.de/listinfo/lively-kernel |
«
Return to Lively Kernel
|
1 view|%1 views
| Free forum by Nabble | Edit this page |