Hi,
El lun 23 ene 2012 01:18:48 COT, HansBKK escribió:
Thanks Offray for your detailed and informative response.
Well I'm enjoying also these talks with you. I think that putting
documentation also in the center is required if we want to break the
Leo's self-fulfilled prophesy about being a "ghetto tool" for
programmers only and I want this in the best way.
[..]
I for some reason missed the MoinMoin's "simple page storage" option - thanks so
much for pointing that out. For all the reasons you cite, and most importantly
is much more mainstream, more actively developed and well-supported than Gitit,
I'll definitely give it a higher priority in my testing.
[...]
I enjoyed using MoinMoin for this project:
http://el-directorio.org/
but at the end we could not intervene MoinMoin as much as we would like
because of the server permissions, that why I started to look more
integrated solutions of the development and deployment environment as
web2py or seaside, but they're not wiki engines properly but web
application frameworks (where you could build a wiki-engine if needed).
But surely
the "sub-optimal distopic world of everything is a file".
I personally disagree with your dislike for "everything is a file" - I see that
principle as a fundamental part of the *nix tool philosophy, and IMO this is a
perfect example:
I certainly think that a distributed off-line collaboration system for
documentation is needed and, if MoinMoin can't
support the use of distributed wikis (and seems is not planned or in
development
To my mind, any wiki platform that can store the page data as plain text (as
opposed to binary/database), in a format suitable for diff tools ("light" markup
as opposed to html/xml) can make use of whatever VCS for
distribution/replication.
You're right and I like the idea of "everything is a something" when
that something is powerful unifying idea. That's the case with Unix's
"everything is a file" or Smalltalk's "everything is an object" (in
Unix you have also every tool makes one thing and makes it right,
combined with pipes). For me these two paradigm's were the ones that,
in 70's, were fighting for the mind share about computer experience of
today and both of them won in a dystopic way, but for me "taking genius
to understand Unix simplicity"[0], was even more dystopic. When you're
trying to empower users the impedance between development and
deployment shows the dystopia, at least compared with the original
visions, so most of the "end users" cant change the tool that changes
them, so, someone else is making decisions about that changes and that
users.
[0] https://en.wikipedia.org/wiki/Unix_philosophy#Quotes
I like the simplicity of light markups and I try myself of not using
explicitly nothing as xml and I like also the idea of the light markup
being used by VCS tools. That's not where dystopia lies. The problem is
not about files or structure but about "meta-structure" (structure
talking about structure, as in meta-languages), specially
self-referential meta-structure, because self-referential
meta-structures are the key for self-directed change, as opposed with
change directed by others. When you see how the "world of everything is
a file" talks about itself, there is a lot of impedance and
discontinuity between source code, binary, apps and docs and there is a
long path for the user who is confined to using apps to create docs,
but never change the apps that could let she/he to change his/her
writing and that's why I want to use Leo this semester with
non-technical writers to explore the way that writing change the tool
that writes and not only the human who does.
For me a unified emergent meta-structure in the world of "everything is
a file" is where lies the power of Leo. You can use an outline to
change the way that Leo behaves and that's why having the Leo's
self-referential meta-structure is more powerful that the "dystopic
world of everything is a file" (in that world you don't have
meta-structure, only structure, mostly for storage purposes and the
intelligence to read/process it is mostly outside the file, in the
human reader, the compiler or the binary). What Leo does is to create
self-referentiality in the world of everything is a file by introducing
outlines that can talk/structure the files and that can talk about
outlines, i.e outlines that can talk about files and about themselves
and can reprogram the way Leo itself works, and so Leo is bridging the
gap between objects and files in a valuable and unique way. But we
need still to improve, specifically we need a more elegant way to talk
about that files, specially about their changes in time, because is in
that change where talking with the distopic world has more problems and
possibilities, and that way I'm making the Fossil/VCS experiment and
also.
Wow I think that this is the first time I have the opportunity to write
(curiously in English instead of my native tongue) about that dystopy,
because most of the time I just talk about this with my students or
friends but not as detailed and contextually, so thanks for bring this
up Hans, and thanks everyone else here who is still reading :-)
On a related matter one of the problems I see with actual server technology
is its gigantism which concentrates
power in the people who has the resources, knowledge and time to possess,
understand and administer/intervene this technology so a Global South Test
for me about which server technology to choose is: "it runs from a USB
thumb
drive?".
IMO "server" is a function, not a question of scale or complexity - the better
question for my workflow is "does the app run portably?". I personally find
actually running stuff from flash drives too slow and data-dangerous.
I'm agree with you. Server and gigantism have not to be equal, but
unfortunately in the "dystopic informatic world" (where the previous
dystopia is just a part) they're most of the time. Portability is the
key, not flash drives. In my context they're just a medium to ask the
same as you, but also a way to let people take the technology with
them, no matter if they have access to a "classical" server.
So far I've found that anything that runs under Linux is inherently portable in
that sense.
Agreed. Having Leo + Fossil + Laptop ( ;-P ) gives me some kind of
portability, but we need more. That's why I think that we need a self
contained version of Leo with a default discourse about file flat world
change in time (at least for Windows), but ideally would be nice to
have something like the self-contained multiplatform Pharo's One Click
Experience[1]
[1] http://www.pharo-project.org/pharo-download
This, for example, favors Web2py/Smalltalk instead of Zope and Fossil
instead of GitHub.
I haven't any experience with these others, but note that Git does not = GitHub.
I share your dislike for server/storage platforms out of my direct control, not
least for privacy/security issues for many use cases. If I used Git for data
distribution I wouldn't use GitHub, and my understanding is that even "Git for
Windows" is already fully portable.
Oohh I don't make myself clear, sorry. Fossil compared with GitHub was
not because of the equivalence of Git and GitHub, but because of the
integration of web characteristics of GitHub in Fossil (wiki, tickets,
web interface and so on).
For myself, I think mercurial would be a good fit, but my main point is that any
moves toward a "distributed Leo" should IMO be VCS-agnostic, just as my plans
for enabling community editing of Leo-managed content will be wiki-platform
agnostic.
I fully share your opinion on that subjects, but in this case I want to
start by some specific implementation from which one start to abstract
that to think abstractly without any particular implementation in the
road, which is not your case, I just point to different implementation
strategies based on the same agnosticism/diversity as a valuable thing
to preserve.
To me, the key enabler for that is "everything as a file". . .
For me the enabler is self-referential meta-structure
Thanks,
Offray
--
You received this message because you are subscribed to the Google Groups
"leo-editor" group.
To post to this group, send email to leo-editor@googlegroups.com.
To unsubscribe from this group, send email to
leo-editor+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/leo-editor?hl=en.
