Wiki Ide

Inspired from ProgrammingInWiki

A 'Wiki IntegratedDevelopmentEnvironment' or WikiIde would be a collaborative development environment for applications and services, and probably suites of such.

The virtues one would expect of any modern Wiki would be part of the WikiIde (if it is to deserve the 'Wiki' name) - these include:

Similarly, one would expect certain properties associated with programming languages and IDEs: Properties required as a Collaborative Web & Code Services platform: Wishlist: In many ways, a WikiIde is nearly a full-blown operating system. This is hardly a unique property to WikiIde, of course (a great many IDEs, such as those for Lisp, Smalltalk, Ruby, Erlang, etc. are essentially operating systems minus the device drivers). In any case, if we have a WikiIde written in WikiIde such that it can be repackaged for bare metal, it wouldn't be a bad idea to actively explore the possibility of running it on bare metal using a variety of WikiWord services for hardware-access and resource management as well as the browsers themselves. Perhaps it could be reversed, and OS ideas could be added to flesh out the WikiIde (see NewOsFeatures, ObjectBrowser).


Aside from being an interesting curiosity, what would a WikiIde give you that couldn't be achieved equally well (or better - editing code in a browser textbox sounds grim) with the combination of conventional Wikis, Web-based forums, email mailing lists, or other communications tools used with conventional IDEs and a source control management system?

In what way to "conventional IDEs and source control management systems" use the schema of hyperWords and the power and diversity that their linking and architecture provide? What is so grim about editing text in a textbox? It is easy, as this wiki demonstrates. Perhaps there are social and personal issues to be overcome which make implementation of a WikiIde more difficult than the technical issues which it presents. It seems to me that this concept is more than a simple curiosity, and that it is part and parcel of a new wave of thinking and implementation which makes the workplace mobile and virtual rather than fixed and physical. -- DonaldNoyes.20080227.1613.mo6

What "power and diversity" does a "schema of hyperWords" and "their linking and architecture" provide?

This is adequately exposed in the proposal starting at the top of the page with "The virtues one would expect of any modern Wiki" and ending with "the entire wiki" (1400 words)


Aside from being an interesting curiosity, what would a WikiIde give you that couldn't be achieved equally well (or better - editing code in a browser textbox sounds grim) with the combination of conventional Wikis, Web-based forums, email mailing lists, or other communications tools used with conventional IDEs and a source control management system?

A page named ProgrammingInWiki discusses potential benefits. Editing in a textbox isn't so bad - I'm sure a little AJAX support could even give you syntax highlighting. Instead of anything technical, I'll perhaps offer some snapshot UserStory(ies) and UserExperience?(s). Feel free to comment. Feel free to contribute if you can come up with something - taking ownership here might close discourse too much. Phrase your own in first person, if you wish.

This rationale makes sense. The justifications [at the top] didn't convince me, - (Technically, the stuff at the top was a list of properties, not a justification for desiring said list of properties. But DonaldNoyes has before expressed himself of the opinion that if hyperWord technology is built, justifications will later be found. He's probably correct.) - but this comes closer. However, I spend much of my day quite happily working in the EclipseIde, I grit my teeth when I have to edit in a browser textbox, and I've written a fair whack of browser-side JavaScript, so I have a very hard time imagining that a browser textbox can provide anywhere near the same speed and functionality, even with (for example) a TiddlyWiki-like festoonment of JavaScript-based enhancement. I suspect the idea will be much more viable (as far as I can see, at least) when browser capability is considerably more advanced than it is now. I'm still skeptical, but I'm starting to like the idea, and would be very interested in exploring the minimal infrastructure necessary to support the essential attributes of a WikiIde. Toward that end, I'd be happy to collaborate on creating a SpikeSolution, and can donate some server resources to trying it. If adequately designed, I believe it should be possible, over time, to evolve the spike into the system described above entirely via the Wiki interface.

ThinkingOutLoud here... I would strive to make the initial kernel, if it can be called that, as minimal as possible, with the goal of moving into a purely Wiki-based editing environment as quickly as possible. This brings to mind the ForthLanguage; it can be ported to a new platform and bootstrapped by implementing only a tiny handful of low-level mechanisms. I would hope a WikiIde would be the same. -- DaveVoorhis


On AJAX and Grim Textbox Interfaces

It wouldn't be impossible to enhance the browsers, too, just to make things easier... i.e. have a Firefox extension for the highlighting or 'improved' view of the Wiki, even if one can get by with the default view. And, frankly, AJAX is something of a weak solution in the long run; if we have get this huge WikiIde running on some awesome language of WikiWords and such, I can't imagine it would be impossible to create a client-side 'scripting' language that simply hooks back into the WikiIde, and eventually use it to replace the "text/java-script" stuff. (Providing browser plugins is relatively easy... the WikiIde could even host them so you can download them wherever you go.)

I've been studying up on AJAX and CSS, thinking about syntax highlighting and mechanisms for implementing a 'sweet' update interface. I'd like to see as follows on the EditPage:

Ajax and CSS are powerful enabling technologies for this sort of stuff, and I have no doubt that ALL of the above can be done - if not right away, then as the WebServer is upgraded from within the WikiIde (I'm aiming for a RuntimeUpgradeableCore). Actually, I bet that a good chunk of it could be done right away, and a good bit of that should be done right away, but I will not press for it. More advanced ObjectBrowser or plugin-based approaches would allow for greater efficiency and flexibility and IO-support, but requirement for them should be kept away from the basic WebServer product, and should be utilized either through particular services (e.g. when running a page as a CGI) or over special ports (since creating services inside the WikiIde to handle inputs on special IP ports should also be possible). (i.e. make users log into special ports or hook into particular services running ON the WikiIde to get advanced stuff).

I'm currently split on the idea of interjecting a component or two (potentially XsltLanguage) between the WebServer and the pages that has the general task of describing pages/URIs + a high-level 'purpose' as some sort of high-level InteractiveSceneGraph, such that the WebServer acts as a 'backend' to compile these high-level InteractiveSceneGraph back down into HTML & JavaScript & XMLHTTPRequest. One one hand: YouAintGonnaNeedIt (yet) - it would eventually allow for more flexible client-end support (especially regarding use of ObjectBrowsers). On the other hand, it might actually be simpler to inject two high-level transforms (with XsltLanguage or similar) than it is to write one low-level transform by hand, and coming up with this intermediate layer would offer a fine place to think about how to do it properly. I guess the choice will depend upon whether the SpikeSolution has a webserver that supports XML pipelining, and whether it seems the necessary output (which has JavaScript - but not necessarily very dynamic JavaScript) is easily done with the available tools.


I hereby claim dibs on the name "Wikid", even though at least two projects (bastards!) has already (mis)used the name for unrelated things. :) -- DaveVoorhis

Maybe WikiHeart?? I tossed it out as a name for the WikiIde open-port bindings page (in RuntimeUpgradeableCore), but it'd make a neat name for a WikiIde, and it would have the benefit of providing a clear project-name for updating the 'kernel' of the WikiIde from within the WikiIde (whereas 'wikid' sounds more like something you'd manipulate primarily from a unix command-line).

WikiHeart? is a bit too squishy and lovey for my taste, but maybe it will appeal to others. I can imagine the "I Wiki<3" bumper stickers and T-shirts. If it were left up me (thankfully, it isn't) I'd be more inclined to go with WiKernel?, or WiKore?, or something like that. -- DaveVoorhis

KingdomWikiHeart et al., eh? It is a bit Disney-esque. OpenIde? and WikiForge? would also be good (ForgeCore?).

I hope implementation won't have to wait until a particular is complete, lest this project be condemned to one of those infinite regresses where <x> can't be built until it can run on <yOS> which depends on <zLanguage> which will only run on <qPlatform>, which can't be written until <tSystem> is finished, and so on. (Or until it's proven that <tSystem> depends on <x>...) If it were me, I'd try to bodge together a quick-'n'-dirty minimal SpikeSolution out of existing tools, use it long enough to hate it (but learn from it), then throw it away and start over properly. I.e., BuildOneToThrowAway?. -- DaveVoorhis


Here's my ThinkingOutLoud (written in some haste) re bootstrapping a usable WikiIde:

There are four fundamental subsystems:

The fundamental constraints are as follows: This is very back-of-napkin at the moment; I've been writing it as I conceive it, so it may be fundamentally flawed. I worry, in particular, that there may be dependency chains where breakage in a single rung may bring down the system. However, I think it should provide an (essential) independence between the languages used to implement the system and the system itself, and permit changing these as required. It also means it can be deployed with a minimum of development and can use existing tools - such as an Apache HTTP server and its source code, the Subversion revision control system and its source code, Perl/Python/PHP/Ruby/C/C++/etc. compilers/interpreters and associated source code, and any standard OS capable of running these.

-- DaveVoorhis

I really like the use of heartbeat monitors - a system with two hearts where each can fix the other and one can fix the system is a fairly good basis for stability. I'll add them to the approaches listed in RuntimeUpgradeableCore (to be used in combination with, not instead of). Obviously you're depending on an external scheduler to support the heartbeat monitors, but (for the SpikeSolution) I think that choice is appropriate; in the long run, I want the primary scheduler to be part of the WikiIde, which is necessary so it can be upgraded from within the WikiIde to support distributed operations and server-farms and bare-metal installation. This, of course, means that the heartbeat monitors will almost certainly be running on an upgradeable scheduler. Fun, eh? The scheduler + network reachibility (either of which is useless without the other) will ultimately be primary points-of-failure in the WikiIde system (whether it is distributed or not), which really means that we'll want to eventually support the construction of rescue-disks.

On the User Space issue, I believe that proper Project and ProjectPage control would be sufficient to the task. In particular, the Heartbeat and Secondary Heartbeat and Kernel projects can 'depend' on these files at build-time, but the pages utilized by the project shall be selected at a particular version-identifier - aka. a logical 'freeze'. All projects, not just the forge service project and its hearts, shall have this ability to (logically) freeze pages so they aren't upgraded whenever said page is modified. In a sense, I really want all projects to be first-class entities, on exactly the same logical level as the WikiIde core services (and even capable of adding to the open IP ports, albeit only through a particular (potentially capability-secured) page).

I'm not convinced of the value of attempting to support multiple languages; the ability to properly and meaningfully link and integrate and modify service (typically just the content of the page being served), not the ability to compile and run services, is what the 'Wiki' aspect is all about. The use of the OS executive environment creates a very fragile and largely unintegrated and poorly linked system that I fear will fall apart quite easily, and it will also have the failings for multiple-languages that I described in ProgrammingInWiki. And if the OS is used for some 'special' things and not for everything else, then the WikiIde really isn't a first-class service of the WikiIde.

Consider if our WikiIde did support upgrading Apache. This means supporting Makefiles, C++, a Filesystem filled with C++ '.h', '.hpp', '.cpp' pages (of which only the '.h' pages could essentially be referenced from other pages) possibly automake, and lots and lots of directories. I won't even consider trying to make the C++ language & compiler itself upgradeable - that doesn't get pretty. The 'WikiWay' would involve describing services or algorithms or values or data on pages identified by WikiWords on, as much as possible, a 'flat' namespace (excepting where projects need special implementations, common page-addendums like discussions, user:prefs, etc.). This avoids any need to:specify:words:like:this or worse (namespaces at least can be associated with 'using namespace' declarations and autogen disambiguation lists). In the WikiWay, these external algorithms, values, and data are automatically integrated into the local project where the WikiWord names are used, which requires using a language that knows how to do the integration (i.e. a common language, or a 'super'-language that is really smart about it). In addition to providing an example of what not to do (and one taking tons and tons of pages), the Apache implementation would also divide mindshare when it comes to fixing perceived 'webserver' problems: one can go about attempting to fix Apache or some component of it, or one can start building a WebServer that really is a FirstClass WikiIde product.

We may be better off with having the WebServer and such be considered 'external' and SecondClass system until such a time as we are able to create a project within the WikiIde that can allow for porting of the service. Thus, instead of attempting to treat the webserver and scripts and heartbear monitors as some sort of FirstClass WikiIde project from the beginning, we simply use it as a scaffolding; and, while being supported by the scaffolding, we build the service to our own vision (so that later we can upgrade it from within the Wiki), run a bunch of tests, then carefully (by hand, and with a system backup available should we fail) remove the scaffolding and henceforth utilize the FirstClass implementation. and the various other services. I.e. we essentially bootstrap every single service by hand. And the core component we need to be there, from the beginning, is the language. (This is essentially the roadmap I possessed.)

Not that I'm dissing your design or the constraints, and I certainly like the heartbeat monitors. But, keeping in mind the bigger picture of the WikiIde goals, I foresee the attempt described above (even if you intend it be there only for the SpikeSolution) to be ultimately harmful to my goals with the WikiIde. I also fear that it will become almost impossible, or at least a significant battle, to ever wean the WikiIde off these early influences. (Or perhaps I misinterpreted you when you said that, say, the web server could be upgraded just like any other part of the system? Let me know if it appears I've misunderstood your intentions.)

Security Concerns for SpikeSolution

We can't really afford to expose 'system("rm -rf /")' (or any equivalent thereof) through our WikiIde SpikeSolution... not without having to password protect everything and be extremely careful about who we allow to play in the sand. I think that we'll need to have a security solution built into our SpikeSolution before we open anything to the public.

At the very least, we need to have signed users to whom we can then assign capabilities. It's somewhat difficult to give a capability to a user when they don't have an authorized handle.

I've addended the above to adjust for this.


Today, these first and second heartbeed monitors are named ContinuousIntegration.

No. ContinuousIntegration pre-dates the notion of using heartbeat monitors. Heartbeat monitors, as described above, are a specific technical architecture that prevents WikiIde authors from irretrievably breaking a live WikiIde via erroneous modifications to its own core code. ContinuousIntegration is a broad vision of development, at best a general strategy -- it is not a specific architecture.

It would be more accurate to say that the heartbeat monitors are technical infrastructure that makes it safe to perform ContinuousIntegration on a WikiIde's kernel via the WikiIde itself.

I've initiated a project http://keinze.mbwiki.de/pmwiki.php?n=Main.Mbwiki -- MirkoBlueming 21.05.2012


Anything happening here recently? Just wondering whether people have noticed BespinEditor, which seems a good candidate to build a WikiDE.


Contributors: DaveVoorhis

MarchZeroEight

SeeAlso: QedWiki, ProgrammingInWiki, WikiOs, OsWiki, ReflectiveWiki, WikiWithProgrammableContent, BespinEditor


CategorySoftwareTool


EditText of this page (last edited May 21, 2012) or FindPage with title or text search