[425694] [proposal] technology.handly
Bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=425694
diff --git a/technology.handly/_projectCommon.php b/technology.handly/_projectCommon.php
new file mode 100644
index 0000000..741b7e0
--- /dev/null
+++ b/technology.handly/_projectCommon.php
@@ -0,0 +1,3 @@
+<?php
+include("../_proposalCommon.php");
+?>
diff --git a/technology.handly/functions.php b/technology.handly/functions.php
new file mode 100644
index 0000000..432bb72
--- /dev/null
+++ b/technology.handly/functions.php
@@ -0,0 +1,55 @@
+<?
+/*******************************************************************************
+ * Copyright (c) 2007 Eclipse Foundation and others.
+ * All rights reserved. This program and the accompanying materials
+ * are made available under the terms of the Eclipse Public License v1.0
+ * which accompanies this distribution, and is available at
+ * http://www.eclipse.org/legal/epl-v10.html
+ *
+ * Contributors:
+ * Wayne Beaton (Eclipse Foundation)- initial API and implementation
+ *******************************************************************************/
+
+function get_title_from_html_document($file_name) {
+ $header = get_header_from_html_document($file_name);
+
+ /*
+ * Break the header up into multiple lines. Handle the
+ * case where line breaks are lf, crlf, or cr.
+ */
+
+ $lines = preg_split("/\r?\n|\r/", $header);
+
+ /*
+ * Merge the lines into a single line so that eregi
+ * can find the title even if it is split over multiple
+ * lines
+ */
+ $one_line = implode(" ", $lines);
+
+ /*
+ * If we can match a title tag, extract it.
+ */
+ if (eregi("<title>(.*)</title>", $one_line, $title)) {
+ return $title[1];
+ }
+
+ return "An Eclipse Proposal";
+}
+
+function get_header_from_html_document(&$file_name) {
+ $handle = @fopen($file_name, "r");
+ $content = "";
+ while (!feof($handle)) {
+ $part = fread($handle, 1024);
+ $content .= $part;
+
+ /*
+ * Only read up to the part that includes the
+ * end tag for the header area.
+ */
+ if (eregi("</head>", $part)) break;
+ }
+ fclose($handle);
+ return $content;
+}
\ No newline at end of file
diff --git a/technology.handly/index.php b/technology.handly/index.php
new file mode 100644
index 0000000..d4afb48
--- /dev/null
+++ b/technology.handly/index.php
@@ -0,0 +1,32 @@
+<?php require_once($_SERVER['DOCUMENT_ROOT'] . "/eclipse.org-common/system/app.class.php"); require_once($_SERVER['DOCUMENT_ROOT'] . "/eclipse.org-common/system/nav.class.php"); require_once($_SERVER['DOCUMENT_ROOT'] . "/eclipse.org-common/system/menu.class.php"); $App = new App(); $Nav = new Nav(); $Menu = new Menu(); include($App->getProjectCommon()); # All on the same line to unclutter the user's desktop'
+
+require_once("functions.php");
+$proposal_title = get_title_from_html_document("proposal.html");
+
+$pageTitle = $proposal_title;
+$pageKeywords = "Eclipse, proposal";
+$pageAuthor = "";
+
+
+ob_start();
+?>
+<div id="maincontent">
+ <div id="midcolumn">
+
+ <h1><?= $proposal_title ?></h1>
+
+ <?php
+ include_once($_SERVER['DOCUMENT_ROOT'] . "/projects/fragments/proposal-page-header.php");
+ generate_header($proposal_title);
+
+ include("proposal.html");
+ ?>
+ </div>
+</div>
+<?php
+$html = ob_get_contents();
+ob_end_clean();
+
+# Generate the web page
+$App->generatePage($theme, $Menu, $Nav, $pageAuthor, $pageKeywords, $pageTitle, $html);
+?>
diff --git a/technology.handly/proposal.html b/technology.handly/proposal.html
new file mode 100644
index 0000000..46f690c
--- /dev/null
+++ b/technology.handly/proposal.html
@@ -0,0 +1,386 @@
+<!--
+ This document is provided as a template along with some guidance for creating
+ your project proposal. This is just a template. Feel free to change it as
+ you see fit (add sections, remove section). We feel, however, that the
+ suggestions represented in this document represent the reasonable minimum
+ amount of information to move forward.
+
+ Please keep the formatting in this document simple. Please do not edit
+ this document in Microsoft Word as it adds huge piles of markup that make
+ it difficult to restyle.
+
+ More information is available here:
+
+ http://wiki.eclipse.org/Development_Resources/HOWTO/Pre-Proposal_Phase
+
+ Direct any questions about this template to emo@eclipse.org
+ -->
+
+<html>
+<head>
+
+<!--
+ Include the title here. We will parse it out of here and include it on the
+ rendered webpage. Do not duplicate the title within the text of your page.
+ -->
+
+<title>Handly</title>
+</head>
+
+<!--
+ We make use of the 'classic' HTML Definition List (dl) tag to specify
+ committers. I know... you haven't seen this tag in a long while...
+ -->
+
+<style>
+dt {
+display: list-item;
+list-style-position:outside;
+list-style-image:url(/eclipse.org-common/themes/Phoenix/images/arrow.gif);
+margin-left:16px;
+}
+dd {
+margin-left:25px;
+margin-bottom:5px;
+}
+</style>
+
+<body>
+<p>The Handly project is a proposed open source project under the <a
+ href="http://www.eclipse.org/projects/project_summary.php?projectid=technology">Technology
+Top-Level Project</a>.</p>
+
+<!--
+ The communication channel must be specified. Typically, this is the
+ "Proposals" forum. In general, you don't need to change this.
+ -->
+<p>This proposal is in the Project Proposal Phase (as defined in the
+Eclipse Development Process) and is written to declare its intent and
+scope. We solicit additional participation and input from the Eclipse
+community. Please send all feedback to the
+<a href="http://www.eclipse.org/forums/eclipse.proposals">Eclipse Proposals</a>
+Forum.</p>
+
+<h2>Summary</h2>
+
+<p>The Handly project aims to provide a foundation for construction of
+language-oriented handle-based models not unlike the JDT Java Model in
+their essential qualities. It borrows from core design patterns and principles
+used in the Java Model, but aims for a generalized albeit partial basic
+implementation, on top of which complete handle-based models for languages
+of diverse kinds could be built with relative ease. The project includes
+a layer of integration with Xtext.</p>
+
+<h2>Background</h2>
+
+<!--
+ Optionally provide the background that has lead you to creating this project.
+ -->
+
+<p>It is well known that the Java Model is one of the pillars of Eclipse
+Java development tools (JDT). To a great extent, it is the Java Model that
+makes possible seamless tool integration and unified user experience in JDT.
+The Java Model is designed to be a lightweight, fault-tolerant model with
+elements to which a reference can be kept; the model that is well suited
+for presenting in views. It meets those design goals with a handle-based,
+lazily-populated model that keeps no resolved information and wrappers the
+workspace resource model. Meanwhile, models with similar design properties
+might play an equally important role in Eclipse-based development tools
+for other languages.</p>
+
+<p>It seems that core design patterns and principles used in the Java Model
+can be just as relevant to handle-based models for other languages. But as
+the Java Model shows, implementation of those patterns and principles might
+be a nontrivial undertaking. Doing it from scratch, over and over again for
+each language does not appear to be an attractive proposition, especially
+when dealing with languages on a large scale (e.g. DSL engineering). Can
+those patterns and principles be (at least partially) implemented in
+a framework of general usefulness? That is the question that seems
+worthwhile to investigate.<p>
+
+<h2>Scope</h2>
+
+<!--
+ All projects must have a well-defined scope. Describe, concisely, what
+ is in-scope and (optionally) what is out-of-scope. An Eclipse project
+ cannot have an open-ended scope.
+ -->
+
+The project is going to encompass the following areas of work:
+
+<ul>
+ <li><b>Core framework.</b> The main proposition of the project is a framework
+that attempts to distill the core abstractions of a handle-based model
+into a uniform API and aims to provide the raw materials deemed generally
+useful for implementing such models.</li>
+ <li><b>Common UI components.</b> The API provided by the core framework
+can potentially enable construction of reusable UI components.
+This might be an area for future work.</li>
+ <li><b>Integration with other Eclipse projects.</b> A layer of integration
+with the Xtext project is provided initially. Other integration layers
+may be devised in the future, when and if appropriate.</li>
+ <li><b>Exemplary implementations.</b> To encourage adoption of the framework,
+comprehensive examples of its use must be provided. These examples would be
+most fruitful if they could also serve as practical tools.</li>
+</ul>
+
+<h2>Description</h2>
+
+<!--
+ Describe the project here. Be concise, but provide enough information that
+ somebody who doesn't already know very much about your project idea or domain
+ has at least a fighting chance of understanding its purpose.
+ -->
+
+<p>It can be said that handle-based models are an important ingredient in
+an Eclipse IDE, if only because the workspace resource model is handle-based.
+The handle-based Java Model of JDT provides further evidence. The Java Model
+also shows that the (programming-language agnostic) resource model is often
+not enough: a language or a group of languages may need its own handle-based
+model that defines a code-centric view on resources and supports navigation
+down to structural elements inside a source file (which requires parsing
+the contents of the file). It is this class of language-oriented handle-based
+models that is the main interest of this project.</p>
+
+<p>The project aims to investigate technology needed to deal with such
+handle-based models on a large scale. In particular, the project will attempt
+to distill the core abstractions of a handle-based model into a uniform API
+and supply basic building blocks for construction of such models. It borrows
+heavily from some of the design patterns and principles used in the Java Model,
+but aims for a generalized albeit partial implementation.</p>
+
+<p>Thus, the project will provide a uniform API and a partial implementation for
+the central notion of a handle that acts like a key to a model element and has
+the following principal characteristics:</p>
+
+<ul>
+ <li>a value object - immutable, equality isn't based on identity</li>
+ <li>can define the behavior of an element, but doesn't keep any element
+state (beyond the key information) - lightweight, never stale, references can
+be kept for a long time</li>
+ <li>can refer to non-existing elements - existence can be tested with
+exists()</li>
+</ul>
+
+<p>A handle-based design gives a lot of freedom when resolving handles to find
+the corresponding element state (the body). For instance, an implementation
+can maintain a (not strictly) bounded LRU cache of element bodies. The handle
+acts like a key into the cache. The model swaps out bodies to make room for
+other elements (unsaved changes can never be swapped out). Bodies store the
+cached structure and attributes for a particular element and are computed on
+demand. The basic building blocks for such implementation will be supplied
+by the project.</p>
+
+<p>Furthermore, the project will support the notion of a working copy
+(of a source file), its editing and reconciling. A layer of integration
+with Xtext will be provided for editing and reconciling a working copy
+connected to an Xtext editor.</p>
+
+<p>While providing a uniform handle-based API, the project will try to impose
+as minimal restrictions as possible on the shape or the underlying language(s)
+of attainable models.</p>
+
+<h2>Relationship with other Eclipse projects</h2>
+
+<p>The project rests upon the Eclipse Platform and includes a layer of
+integration with Xtext; integration with other Eclipse projects is possible
+in the future.</p>
+
+<p>There are existing efforts at Eclipse that might be viewed as related to
+the project in a way:</p>
+
+<ul>
+ <li><b>The IDE Meta-tooling Platform (IMP)</b> has a much wider scope
+than this project, and a different emphasis. Among other things, it provides
+a 'universal' language-oriented handle-based model, with limited extensibility.
+The current implementation doesn't support elements inside compilation units,
+the notion of a reconcilable working copy, or a handle/body design with a
+bounded LRU cache of bodies, all of which we'll have already covered in the
+initial contribution. More important, our approach is fundamentally different.
+Instead of providing a single complete handle-based model supposed to be a
+universal fit for all languages, we intend to provide an abstract API and a
+partial implementation for constructing any number of specific language-oriented
+handle-based models, with few restrictions on the shape of the model.
+<b>Update:</b> the IMP project has recently been archived (January 2014).</li>
+ <li><b>Dynamic Languages Toolkit (DLTK)</b> provides (among other things)
+an extensible handle-based model intended for dynamic languages. The design
+and implementation are largely influenced by the Java Model. The DLTK model
+does support elements inside source modules and is otherwise similar to the
+Java Model in all essential qualities. However, it is predefined to contain
+elements pertaining to (a subset of) dynamic languages (e.g. a source module
+may contain types, fields and methods; a type may contain fields, methods and
+inner types). We aim to support implementation of custom handle-based models
+of almost arbitrary shapes, for languages of diverse kinds (including
+domain-specific languages).</li>
+ <li><b>Xtext</b> is a wonderful tool for language engineering. It covers
+many important components of an Eclipse-based IDE in a generic and extensible
+way, but does not explicitly address handle-based models. As part of the
+initial contribution we'll provide an integration layer to support editing and
+reconciling of a working copy connected to an Xtext editor. We regard both
+projects as complementary and hope to collaborate with the Xtext team on
+further facilitating construction of handle-based models for Xtext-based
+languages. That said it's our explicit goal to keep the core framework
+completely neutral of any specific language implementation technology and
+encapsulate such dependencies strictly within corresponding integration layers.
+ </li>
+</ul>
+
+<h2>Why Eclipse?</h2>
+
+<!--
+ Answer these two questions: What value does this project bring to the Eclipse
+ community? What value do you expect to obtain from hosting your project at Eclipse?
+
+ What value do you get by having your project at Eclipse over and above the value
+ of hosting at Eclipse Labs?
+ -->
+
+<p>We believe the nature of this project makes Eclipse the right home for it.
+As stated above, handle-based models can play an important role in an
+Eclipse-based IDE. This supports our hope that the area of work to be developed
+by the project might be interesting and useful to the Eclipse community.
+At the same time, such project should definitely benefit from the wider
+exposure with the Eclipse community. We do welcome and hope for open
+participation and contributions from the community; diversity is really
+important for this project to succeed. The project would also benefit from
+the commendable Eclipse development process and IP management.</p>
+
+<h2>Initial Contribution</h2>
+
+<!--
+ Projects are expected to arrive at Eclipse with existing code.
+
+ Describe the existing code that will be contributed to the project. Please provide
+ a couple of paragraphs describing the code with modest detail, including important
+ information like code ownership (who holds the copyright?), and some consideration
+ of community that exists around the code. Include a listing of third-party libraries
+ and associated licenses.
+ -->
+
+<p>The initial code base will be contributed by
+<a href="http://v8.1c.ru/eng/about_1c/">1C LLC</a>
+and includes the core framework and a layer of integration with Xtext.</p>
+
+<p>Although the code is pretty stable and has been used internally with
+promising results, we regard it only as a starting point. The intent is to
+come up with a really nice design in this problem area through an open and
+transparent development process informed by community feedback.</p>
+
+<p>Some parts of the initial design and implementation were adapted from
+Eclipse JDT and Xtext projects. The code makes direct references to the
+following third-party libraries, already present in the Eclipse Orbit
+repository:</p>
+
+<ul>
+ <li>com.google.inject 3.0.0 - Apache License, Version 2.0</li>
+ <li>com.google.guava 10.0.1 - Apache License, Version 2.0</li>
+ <li>org.apache.log4j 1.2.15 - Apache License, Version 2.0</li>
+</ul>
+
+<h2>Legal Issues</h2>
+
+<!--
+ Please describe any potential legal issues in this section. Does somebody else
+ own the trademark to the project name? Is there some issue that prevents you
+ from licensing the project under the Eclipse Public License? Are parts of the
+ code available under some other license? Are there any LGPL/GPL bits that you
+ absolutely require?
+ -->
+
+<p>There are no known legal issues.</p>
+
+<h2>Committers</h2>
+
+<!--
+ List any initial committers that should be provisioned along with the
+ new project. Include affiliation, but do not include email addresses at
+ this point.
+ -->
+
+<p>The following individuals are proposed as initial committers to the project:</p>
+
+<dl>
+ <dt>Vladimir Piskarev, 1C (lead)</dt>
+ <dd>Vladimir is the main developer of the existing framework</dd>
+ <dt>George Suaridze, 1C (co-lead)</dt>
+ <dd>George is an early adopter of the existing framework</dd>
+</dl>
+
+<p>We welcome additional committers and contributions.</p>
+
+<!--
+ Describe any initial contributions of code that will be brought to the
+ project. If there is no existing code, just remove this section.
+ -->
+
+<h2>Mentors</h2>
+
+<!--
+ New Eclipse projects require a minimum of two mentors from the Architecture
+ Council. You need to identify two mentors before the project is created. The
+ proposal can be posted before this section is filled in (it's a little easier
+ to find a mentor when the proposal itself is public).
+ -->
+
+<p>The following Architecture Council members will mentor this
+project:</p>
+
+<ul>
+ <li>Doug Schaefer</li>
+ <li>Marcel Bruch</li>
+</ul>
+
+<h2>Interested Parties</h2>
+
+<!--
+ Provide a list of individuals, organisations, companies, and other Eclipse
+ projects that are interested in this project. This list will provide some
+ insight into who your project's community will ultimately include. Where
+ possible, include affiliations. Do not include email addresses.
+ -->
+
+<p>The following individuals, organisations, companies and projects have
+expressed interest in this project:</p>
+
+<ul>
+ <li>itemis AG</li>
+<!--
+ <li>Somebody else, Affiliation</li>
+-->
+</ul>
+
+<h2>Project Scheduling</h2>
+
+<!--
+ Describe, in rough terms, what the basic scheduling of the project will
+ be. You might, for example, include an indication of when an initial contribution
+ should be expected, when your first build will be ready, etc. Exact
+ dates are not required.
+ -->
+
+<p>The initial contribution is to be expected shortly after creation of the
+project and approval of the Eclipse IP Team. The first milestone build based
+on the initial code base should follow soon after that. Although no exact dates
+are given, we intend to make the initial contribution available to the
+community as soon as technically and legally possible.</p>
+
+<h2>Changes to this Document</h2>
+
+<!--
+ List any changes that have occurred in the document here.
+ You only need to document changes that have occurred after the document
+ has been posted live for the community to view and comment.
+ -->
+
+<table>
+ <tr>
+ <th>Date</th>
+ <th>Change</th>
+ </tr>
+ <tr>
+ <td>10-Jan-2014</td>
+ <td>Document created</td>
+ </tr>
+</table>
+</body>
+</html>
\ No newline at end of file
