On Wed, Jan 4, 2012 at 3:50 AM, Offray Vladimir Luna Cárdenas <[email protected]> wrote: > > Well my approach is that deconstructing textual computer interaction > requires to think in two axes: one of structure in space (Leo outlines are > this) and one of structure in time (DVCS/SCM, specially Fossil are this). So > using my strategy will demonstrate my approach and will have the advantage > of solving a day to day problem in the way that my team and I work and at > the same time could evolve in a more abstract solution as you propose where > Leo DOM could be mapped to database vía DAG or Sea of nodes in a NoSQL > database. Living in the Global South ("Developing Countries" as called by > someones) and working with digital technology is about developing this kind > of strategies that deal with the day to day problems at first, at the same > time that envision some abstract structure. Is about "acting contextually > but thinking systemically".
Okay, but in the absence of a db representation and code to get it in and out of Leo as it is, you will have to be the one to provide it -- only in your case, you're planning additional functionality. You can certainly do that, but I would say understanding of Leo intricacies is the main hurdle. That's what I see as lacking, that somebody can provide either with nothing new or with your feature set. Whichever way it gets done, it's the fact that the db representation and code for loading/saving it are done that will provide the necessary understanding people need to start contributing on the db front. Seth -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en.
