diff options
Diffstat (limited to 'rse/doc/org.eclipse.dstore.doc.isv')
30 files changed, 0 insertions, 1471 deletions
diff --git a/rse/doc/org.eclipse.dstore.doc.isv/.classpath b/rse/doc/org.eclipse.dstore.doc.isv/.classpath deleted file mode 100755 index 3f74547ab..000000000 --- a/rse/doc/org.eclipse.dstore.doc.isv/.classpath +++ /dev/null @@ -1,6 +0,0 @@ -<?xml version="1.0" encoding="UTF-8"?>
-<classpath>
- <classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER"/>
- <classpathentry kind="con" path="org.eclipse.pde.core.requiredPlugins"/>
- <classpathentry kind="output" path="bin"/>
-</classpath>
diff --git a/rse/doc/org.eclipse.dstore.doc.isv/.cvsignore b/rse/doc/org.eclipse.dstore.doc.isv/.cvsignore deleted file mode 100755 index 891527ed8..000000000 --- a/rse/doc/org.eclipse.dstore.doc.isv/.cvsignore +++ /dev/null @@ -1,7 +0,0 @@ -bin -index -build.xml -javadoc.link.location -temp.bin.log -temp.options.txt -temp.convert.txt diff --git a/rse/doc/org.eclipse.dstore.doc.isv/.project b/rse/doc/org.eclipse.dstore.doc.isv/.project deleted file mode 100755 index b79ee8ec5..000000000 --- a/rse/doc/org.eclipse.dstore.doc.isv/.project +++ /dev/null @@ -1,22 +0,0 @@ -<?xml version="1.0" encoding="UTF-8"?>
-<projectDescription>
- <name>org.eclipse.dstore.doc.isv</name>
- <comment></comment>
- <projects>
- </projects>
- <buildSpec>
- <buildCommand>
- <name>org.eclipse.pde.ManifestBuilder</name>
- <arguments>
- </arguments>
- </buildCommand>
- <buildCommand>
- <name>org.eclipse.pde.SchemaBuilder</name>
- <arguments>
- </arguments>
- </buildCommand>
- </buildSpec>
- <natures>
- <nature>org.eclipse.pde.PluginNature</nature>
- </natures>
-</projectDescription>
diff --git a/rse/doc/org.eclipse.dstore.doc.isv/META-INF/MANIFEST.MF b/rse/doc/org.eclipse.dstore.doc.isv/META-INF/MANIFEST.MF deleted file mode 100755 index 793d4eb70..000000000 --- a/rse/doc/org.eclipse.dstore.doc.isv/META-INF/MANIFEST.MF +++ /dev/null @@ -1,8 +0,0 @@ -Manifest-Version: 1.0 -Bundle-ManifestVersion: 2 -Bundle-Name: %pluginName -Bundle-SymbolicName: org.eclipse.dstore.doc.isv; singleton:=true -Bundle-Version: 1.0.0.qualifier -Bundle-Localization: plugin -Eclipse-LazyStart: false -Bundle-Vendor: %providerName diff --git a/rse/doc/org.eclipse.dstore.doc.isv/aaa-how-to-add-things.txt b/rse/doc/org.eclipse.dstore.doc.isv/aaa-how-to-add-things.txt deleted file mode 100755 index d73e72b8e..000000000 --- a/rse/doc/org.eclipse.dstore.doc.isv/aaa-how-to-add-things.txt +++ /dev/null @@ -1,29 +0,0 @@ -Last revised July 27, 2006 -(This file is for information only; it is not included in the release.) - -See also - http://wiki.eclipse.org/index.php/How_to_add_things_to_the_Eclipse_doc -with the following exceptions: -- platformOptions.txt -> options.txt -- overview-platform.html -> /reference/misc/overview-rse.html - -To add new plug-ins you need to make changes in several places in -this doc plug-in: - -1) options.txt -- the plug-in's source folder(s) must be included on the -sourcepath -- code of required plug-ins must be added on the -classpath (the JAR(s)for non-JARed plug-ins and <plugin>/@dot for JARed plug-ins -- the API package names must be included in the (alphabetical) package list at the end of the file -- note that the @sep@ token is replaced during build by the appropriate separator character for the build platform. - -2) buildDoc.xml -- add a line in convertSchemaToHtml target to handle a new plug-ins extension point schemas - -Adding new extension points: - -1) reference/extension-points/index.html -- add a line for each extension point - -2) topics_Reference.xml -- add a line for each extension point -- add a line for each API package
\ No newline at end of file diff --git a/rse/doc/org.eclipse.dstore.doc.isv/about.html b/rse/doc/org.eclipse.dstore.doc.isv/about.html deleted file mode 100755 index 460233046..000000000 --- a/rse/doc/org.eclipse.dstore.doc.isv/about.html +++ /dev/null @@ -1,28 +0,0 @@ -<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" - "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> -<html xmlns="http://www.w3.org/1999/xhtml"> -<head> -<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"/> -<title>About</title> -</head> -<body lang="EN-US"> -<h2>About This Content</h2> - -<p>June 2, 2006</p> -<h3>License</h3> - -<p>The Eclipse Foundation makes available all content in this plug-in ("Content"). Unless otherwise -indicated below, the Content is provided to you under the terms and conditions of the -Eclipse Public License Version 1.0 ("EPL"). A copy of the EPL is available -at <a href="http://www.eclipse.org/legal/epl-v10.html">http://www.eclipse.org/legal/epl-v10.html</a>. -For purposes of the EPL, "Program" will mean the Content.</p> - -<p>If you did not receive this Content directly from the Eclipse Foundation, the Content is -being redistributed by another party ("Redistributor") and different terms and conditions may -apply to your use of any object code in the Content. Check the Redistributor's license that was -provided with the Content. If no such license exists, contact the Redistributor. Unless otherwise -indicated below, the terms and conditions of the EPL still apply to any source code in the Content -and such source code may be obtained at <a href="http://www.eclipse.org">http://www.eclipse.org</a>.</p> - -</body> -</html>
\ No newline at end of file diff --git a/rse/doc/org.eclipse.dstore.doc.isv/book.css b/rse/doc/org.eclipse.dstore.doc.isv/book.css deleted file mode 100755 index 157414c6c..000000000 --- a/rse/doc/org.eclipse.dstore.doc.isv/book.css +++ /dev/null @@ -1 +0,0 @@ -@import "../PRODUCT_PLUGIN/book.css";
diff --git a/rse/doc/org.eclipse.dstore.doc.isv/build.properties b/rse/doc/org.eclipse.dstore.doc.isv/build.properties deleted file mode 100755 index 8788dc44d..000000000 --- a/rse/doc/org.eclipse.dstore.doc.isv/build.properties +++ /dev/null @@ -1,22 +0,0 @@ -############################################################################### -# Copyright (c) 2000, 2006 IBM Corporation 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: -# IBM Corporation - initial API and implementation -############################################################################### -bin.includes = META-INF/,\ - about.html,\ - book.css,\ - notices.html,\ - plugin.properties,\ - plugin.xml,\ - toc.html,\ - toc.xml,\ - guide/,\ - index/,\ - reference/ -customBuildCallbacks = customBuildCallbacks.xml diff --git a/rse/doc/org.eclipse.dstore.doc.isv/buildDoc.xml b/rse/doc/org.eclipse.dstore.doc.isv/buildDoc.xml deleted file mode 100755 index 4701988a4..000000000 --- a/rse/doc/org.eclipse.dstore.doc.isv/buildDoc.xml +++ /dev/null @@ -1,140 +0,0 @@ -<?xml version="1.0" encoding="UTF-8"?> -<project name="RSE DStore ISV Doc Build" default="all" basedir="."> - - <property name="javadoc.link.location" value="${basedir}/javadoc.link.location"/> - - <target name="init"> - <available file="${basedir}/index" property="index.present" /> - <path id="path_bootclasspath"> - <fileset dir="${java.home}/lib"> - <include name="*.jar"/> - </fileset> - </path> - <property name="bootclasspath" refid="path_bootclasspath"/> - <condition property="safeBaseLocation" - value="${baseLocation}" - else="${eclipse.home}"> - <isset property="baseLocation"/> - </condition> - <delete dir="${javadoc.link.location}" /> - </target> - - <target name="computeClasspath" unless="javadoc.classpath"> - <!-- Construct the javadoc classpath and store it in a property. --> - <echo level="info" message="Computing classpath ..."/> - - <!-- Add platform dependencies required by your plug-in here. - Note that this pattern expects Eclipse to have - been installed into the platform directory structure, as is - the case during the build. --> - <patternset id="platform.classpath.pattern"> - <include name="**/org.eclipse.core*.jar"/> - <include name="**/org.eclipse.core*/**/*.jar"/> - <include name="**/org.eclipse.ui*.jar"/> - <include name="**/org.eclipse.ui*/**/*.jar"/> - <include name="**/org.eclipse.osgi*.jar"/> - <include name="**/org.eclipse.osgi*/**/*.jar"/> - <include name="**/org.eclipse.equinox*.jar"/> - <include name="**/org.eclipse.equinox*/**/*.jar"/> - <include name="**/org.eclipse.jface*.jar"/> - <include name="**/org.eclipse.jface*/**/*.jar"/> - <include name="**/org.junit*.jar"/> - <include name="**/org.junit*/**/*.jar"/> - <include name="**/com.ibm.icu*.jar"/> - </patternset> - - <pathconvert property="javadoc.classpath"> - <path> - <fileset dir="${safeBaseLocation}"> - <patternset refid="platform.classpath.pattern"/> - </fileset> - </path> - </pathconvert> - <echo level="info" message="Done computing classpath."/> - <echo level="debug" message="Bootclasspath is: ${bootclasspath}"/> - <echo level="debug" message="Classpath is: ${javadoc.classpath}"/> - </target> - - <target name="extractLinks"> - <mkdir dir="${javadoc.link.location}"/> - - <patternset id="package.list"> - <include name="**/package-list"/> - </patternset> - - <!-- We only need the package-list files out of these --> - <unzip dest="${javadoc.link.location}/platform/"> - <patternset refid="package.list"/> - <fileset dir="${safeBaseLocation}/plugins"> - <include name="org.eclipse.platform.doc.isv*.jar"/> - </fileset> - </unzip> - </target> - - <target name="all" depends="init" unless="index.present"> - <antcall target="convertSchemaToHtml" /> - <antcall target="generateJavadoc" /> - <antcall target="build.index" /> - </target> - - <target name="build.index" description="Builds search index for the plug-in: org.eclipse.dstore.doc.isv" if="eclipse.running"> - <help.buildHelpIndex manifest="${basedir}/plugin.xml" destination="${basedir}" /> - </target> - - <target name="convertSchemaToHtml" if="eclipse.running"> - <property name="dest" value="reference/extension-points" /> - <!-- - <record name="${basedir}/temp.convert.txt" action="start" /> - <pde.convertSchemaToHTML manifest="../org.eclipse.dstore.core/plugin.xml" destination="${dest}" /> - <record name="${basedir}/temp.convert.txt" action="stop" /> - --> - </target> - - <target name="getJavadocPath"> - <available file="${java.home}/../bin/javadoc.exe" property="javadoc" value="${java.home}/../bin/javadoc.exe" /> - <available file="${java.home}/../bin/javadoc" property="javadoc" value="${java.home}/../bin/javadoc" /> - <available file="/usr/bin/javadoc" property="javadoc" value="/usr/bin/javadoc" /> - </target> - - <target name="generateJavadoc" depends="getJavadocPath,extractLinks,computeClasspath" if="javadoc"> - <property name="optionsFile" value="temp.options.txt" /> - <copy file="options.txt" tofile="${optionsFile}" overwrite="true" /> - - <condition property="argsListDelimiter" value=":"> - <os family="unix" /> - </condition> - <condition property="argsListDelimiter" value=";"> - <os family="windows" /> - </condition> - - <replaceregexp file="${basedir}/${optionsFile}" flags="g" match="(\r\n?|\n);" replace="${argsListDelimiter}" /> - <replace file="${basedir}/${optionsFile}" token="@rt@" value="${bootclasspath}${argsListDelimiter}${javadoc.classpath}" /> - <replace file="${basedir}/${optionsFile}" token="@baseLocation@" value="${safeBaseLocation}" /> - <replace file="${basedir}/${optionsFile}" token="@javadoc.link.location@" value="${javadoc.link.location}" /> - - <!--scrub isv plugin directories of any preexisting api doc content--> - <delete dir="reference/api" /> - <mkdir dir="reference/api" /> - - <echo message="sep = ${argsListDelimiter}"/> - <echo message="javadoc = ${javadoc}"/> - <exec dir="." executable="${javadoc}" output="temp.bin.log"> - <arg line="@${basedir}/${optionsFile} -J-Xmx1000M" /> - </exec> - </target> - -</project> - - - - - - - - - - - - - - diff --git a/rse/doc/org.eclipse.dstore.doc.isv/customBuildCallbacks.xml b/rse/doc/org.eclipse.dstore.doc.isv/customBuildCallbacks.xml deleted file mode 100644 index e457715e4..000000000 --- a/rse/doc/org.eclipse.dstore.doc.isv/customBuildCallbacks.xml +++ /dev/null @@ -1,157 +0,0 @@ -<!-- ===================================================================== --> -<!-- Custom targets called from a project's generated build.xml --> -<!-- Set customBuildCallbacks=<path/to/this/file> in your build.properties.--> -<!-- ===================================================================== --> -<project name="Build specific targets and properties" default="noDefault"> - - <!-- ===================================================================== --> - <!-- Default target --> - <!-- ===================================================================== --> - <target name="noDefault"> - <echo message="This file must be called with explicit targets" /> - </target> - - <!-- ===================================================================== --> - <!-- Steps to do before the target build.jars --> - <!-- Available parameters : --> - <!-- build.result.folder - folder to contain the build results --> - <!-- ===================================================================== --> - <target name="pre.build.jars"> - </target> - - <!-- ===================================================================== --> - <!-- Steps to do after the target build.jars --> - <!-- Available parameters : --> - <!-- build.result.folder - folder to contain the build results --> - <!-- ===================================================================== --> - <target name="post.build.jars"> - <ant antfile="buildDoc.xml" /> - </target> - - <!-- ===================================================================== --> - <!-- Steps to do before the target build.sources --> - <!-- Available parameters : --> - <!-- build.result.folder - folder to contain the build results --> - <!-- ===================================================================== --> - <target name="pre.build.sources"> - </target> - - <!-- ===================================================================== --> - <!-- Steps to do after the target build.sources --> - <!-- Available parameters : --> - <!-- build.result.folder - folder to contain the build results --> - <!-- ===================================================================== --> - <target name="post.build.sources"> - </target> - - <!-- ===================================================================== --> - <!-- Steps to do before the compilation target <name> --> - <!-- Substitute "name" with the name of the compilation target, eg @dot --> - <!-- Available parameters : --> - <!-- source.foldern : n = 1 ... N, the source folders --> - <!-- target.folder : where the results of the compilation go --> - <!-- <name>.classpath : name = name of the compilation target. A --> - <!-- reference to the classpath structure. --> - <!-- ===================================================================== --> - <!-- - <target name="pre.compileTarget.jar"> - </target> - --> - - <!-- ===================================================================== --> - <!-- Steps to do after compilation but before jaring --> - <!-- Substitute "name" with the name of the compilation target, eg @dot --> - <!-- Available parameters : --> - <!-- source.foldern : n = 1 ... N, the source folders --> - <!-- target.folder : where the results of the compilation go --> - <!-- <name>.classpath : name = name of the compilation target. A --> - <!-- reference to the classpath structure. --> - <!-- ===================================================================== --> - <!-- - <target name="post.compile.compileTarget.jar"> - </target> - --> - - <!-- ===================================================================== --> - <!-- Steps to do after the compilation target <name> --> - <!-- Substitute "name" with the name of the compilation target, eg @dot --> - <!-- Available parameters : --> - <!-- jar.location - the location of the compilation results --> - <!-- <name>.classpath : name = name of the compilation target. A --> - <!-- reference to the classpath structure. --> - <!-- ===================================================================== --> - <!-- - <target name="post.compileTarget.jar"> - </target> - --> - - <!-- ===================================================================== --> - <!-- Steps to do before the target gather.bin.parts --> - <!-- Available parameters : --> - <!-- base.dir - root of the project --> - <!-- build.result.folder - folder containing the build results --> - <!-- target.folder - destination folder --> - <!-- ===================================================================== --> - <target name="pre.gather.bin.parts"> - </target> - - <!-- ===================================================================== --> - <!-- Steps to do after the target gather.bin.parts --> - <!-- Available parameters : --> - <!-- base.dir - root of the project --> - <!-- build.result.folder - folder containing the build results --> - <!-- target.folder - destination folder --> - <!-- ===================================================================== --> - <target name="post.gather.bin.parts"> - </target> - - <!-- ===================================================================== --> - <!-- Steps to do before the target gather.sources --> - <!-- Available parameters : --> - <!-- destination.temp.folder - destination folder --> - <!-- ===================================================================== --> - <target name="pre.gather.sources"> - </target> - - <!-- ===================================================================== --> - <!-- Steps to do after the target gather.sources --> - <!-- Available parameters : --> - <!-- destination.temp.folder - destination folder --> - <!-- ===================================================================== --> - <target name="post.gather.sources"> - </target> - - <!-- ===================================================================== --> - <!-- Steps to do before the target gather.logs --> - <!-- Available parameters : --> - <!-- destination.temp.folder - destination folder --> - <!-- ===================================================================== --> - <target name="pre.gather.logs"> - </target> - - <!-- ===================================================================== --> - <!-- Steps to do after the target gather.logs --> - <!-- Available parameters : --> - <!-- destination.temp.folder - destination folder --> - <!-- ===================================================================== --> - <target name="post.gather.logs"> - </target> - - <!-- ===================================================================== --> - <!-- Steps to do before the target clean --> - <!-- Available parameters : --> - <!-- destination.temp.folder - destination folder --> - <!-- ===================================================================== --> - <target name="pre.clean"> - </target> - - <!-- ===================================================================== --> - <!-- Steps to do after the target clean --> - <!-- Available parameters : --> - <!-- plugin.destination - final destination of the build --> - <!-- build.result.folder - results of the compilation --> - <!-- temp.folder - temporary folder --> - <!-- ===================================================================== --> - <target name="post.clean"> - </target> -</project>
\ No newline at end of file diff --git a/rse/doc/org.eclipse.dstore.doc.isv/guide/Artifacts.html b/rse/doc/org.eclipse.dstore.doc.isv/guide/Artifacts.html deleted file mode 100755 index 3b35774b0..000000000 --- a/rse/doc/org.eclipse.dstore.doc.isv/guide/Artifacts.html +++ /dev/null @@ -1,64 +0,0 @@ -<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> -<html> -<head> -<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=UTF-8"> -<META HTTP-EQUIV="Content-Style-Type" CONTENT="text/css"> -<meta name="copyright" content="Copyright (c) IBM Corporation and others 2000, 2006. This page is made available under license. For full details see the LEGAL in the documentation book that contains this page." > -<title>RSE Artifacts</title> -<link rel="stylesheet" type="text/css" HREF="../book.css"> -</head> - -<body> -<h1>DataStore Artifacts</h1> -<p>With the DataStore, you interface the following artifacts:</p> -<ul> -<li><A href="#clientconnection">Client Connection</A></li> -<li><A href="#datastore">DataStore</A></li> -<li><A href="#dataelement">DataElement</A></li> -<li><A href="#miner">Miner</A></li> -</ul> -<p>All the classes and interfaces mentioned here are defined in the <samp>org.eclipse.dstore.core</samp> plugin. - -<h2><A name="clientconnection">Client Connection</A></h2> -<p> -The <b>ClientConnection</b> class is used for establishing a DataStore connection. This class provides the -means to instantiate a client DataStore and connect to a server DataStore on a specified host running under a -specified port. The connection to the server DataStore may either be made directly or a startup -negotiation may be made with a remote daemon before connecting to the server. This class also provides the means -for disconnecting from the DataStore. -</p> - -<h2><A name="datastore">DataStore</A></h2> -<p> -The <b>DataStore</b> class is the heart of the DataStore communications framework. An instance of a DataStore contains a tree -of <a href="#dataelement">DataElements</a>. This tree can be referred to as the <i>DataStore repository</i> because -it consists of all the schema information and data content used. Any type of object or relationship defined, command definition or -piece of data that needs to be communicated between the client and server are stored in the <i>DataStore repository</i>. -The DataStore class can be used for finding, creating and deleting DataElements and for communicating commands -to <a href="#miner">miner</a>. The DataStore class encapsulates all remote synchronizations between the client and the -server via its <code>command</code> and <code>refresh</code> APIs. -</p> - -<h2><A name="dataelement">DataElement</A></h2> -<p> -The <b>DataElement</b> is the unit of information in a DataStore repository. Each DataElement has a set of attributes that describe -the object it represents and is related to other DataElements by containing other DataElements. DataElements represent both the meaning -of data as well as the data itself. -</p> -<p> -For more information about DataElements, see the section, <a href="DataElements.html">DataElements and the DataStore model</a>. -</p> - -<h2><A name="miner">Miner</A></h2> -<p> -A <b>Miner</b> is an extension point to the DataStore. Miners are classes, residing on the server-side, that implement a common -interface used by the DataStore for communication information between the DataStore and the tools. -</p> -<p> -For more information about Miners, see the section, <a href="Miners.html">Miners</a>. -</p> -</body> -</html> - - - diff --git a/rse/doc/org.eclipse.dstore.doc.isv/guide/ClientSide.html b/rse/doc/org.eclipse.dstore.doc.isv/guide/ClientSide.html deleted file mode 100755 index c2fb661a7..000000000 --- a/rse/doc/org.eclipse.dstore.doc.isv/guide/ClientSide.html +++ /dev/null @@ -1,171 +0,0 @@ -<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> -<html> -<head> -<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=UTF-8"> -<META HTTP-EQUIV="Content-Style-Type" CONTENT="text/css"> -<meta name="copyright" content="Copyright (c) IBM Corporation and others 2000, 2006. This page is made available under license. For full details see the LEGAL in the documentation book that contains this page." > -<title>Tutorials</title> -<link rel="stylesheet" type="text/css" HREF="../book.css"> -</head> - -<body bgcolor="#ffffff"> -<h1>Communicating with the Server-side</h1> - -<h2>Connecting to a Local DataStore</h2> -<p> -If you're writing an RSE subsystem to connect to a local standalone DataStore, the following needs -to be done during the connect: -</p> - -<font color='#4444CC'> -<pre> - ... - ClientConnection clientConnection = new ClientConnection(connectionName); - - // initialize the local datastore - clientConnection.localConnect(); - - DataStore dataStore = clientConnection.getDataStore(); - - // specify miners to load - dataStore.addMinersLocation("."); // initializes the default miners - - // initialize miners - dataStore.getSchema(); - dataStore.initMiners(); - ... - -</pre> -</font> - -<h2>Connecting to a Remote DataStore</h2> -<p> -If you're writing an RSE subsystem to connect to a remote DataStore, the only difference -from the local scenario is that <code>connect</code> is called rather than <code>localConnect</code>. -</p> - -<font color='#4444CC'> -<pre> - ... - ClientConnection clientConnection = new ClientConnection(connectionName); - - // prepare connection - clientConnection.setHost(hostName); - clientConnection.setPort(port); - - // connect - clientConnection.connect(ticket); - - DataStore dataStore = clientConnection.getDataStore(); - - // specify miners to load - dataStore.addMinersLocation("."); // initializes the default miners - - // initialize miners - dataStore.getSchema(); - dataStore.initMiners(); - ... - -</pre> -</font> - -<h2>Loading an Additional DataStore Miner</h2> -<p> -If the new miner has been registered via the default minerFile.dat file, then -no further steps are required to load it. Otherwise, after the subsystem is -connected to the remote DataStore, you need to tell the DataStore to load the -miner as follows. -</p> - -<font color='#4444CC'> -<pre> - ... - dataStore.addMinersLocation(location); - dataStore.getSchema(); - ... -</pre> -</font> - -<p> -This tells the host DataStore to instantiate and initialize all miners listed in -the specified minerFile.dat file. -</p> - - -<h2>Sending Commands to a Miner</h2> -<p> -To send a command to a miner, the required <a href="DataElements.html#commanddescriptor">command descriptor</a> must first be obtained -using the method <code>DataStore.localDescriptorQuery</code>. The method <code>DataStore.command</code> is then called with command -descriptor and the subject of the command. For example, a query might need to be called on the miner as shown in the following code segment. -</p> - -<font color='#4444CC'> -<pre> - ... - // the UI model object - MyRemoteObject obj = getMyRemoteObject(); - - // get the corresponding DataElement for this object - DataElement deObj = obj.getDataElement(); - - // get the DataStore from the DataElement - DataStore ds = deObj.getDataStore(); - - // get the query command descriptor for the subject - DataElement queryCmd = ds.localDescriptorQuery(deObj.getDescriptor(), "MY_QUERY_COMMAND"); - - // send the command - DataElement status = ds.command(queryCmd, deObj, true); - ... -</pre> -</font> - -<h2>Receiving Data from a Miner</h2> -<p> -After a command is sent to a miner, you might want to receive information that the miner produced in response to the command. -DataStore commands and responses are sent asynchronously, much like events. On the server, the -<a href="Communications.html#servercommandhandler">Server Command Handler</a> reacts to incoming commands by calling the <code>handleCommand</code> -method on the appropriate miner. For the client, the <a href="Communications.html#clientcommandhandler">Client Command Handler</a> -reacts to incoming responses by firing domain notifications. In order to receive miner responses, asynchronously, -you need to implement a DataStore domain listener. -</p> -<p> -A domain listener implements the IDomainListener interface. An instance of an IDomainListener needs to be added to the DataStore domain listener -list. The following is what a simple domain listener looks like: -</p> - -<font color='#4444CC'> -<pre> - public class MyDomainListener implements IDomainListener - { - public boolean listeningTo(DomainEvent e) - { - // check if we care about this event - ... - } - - public void domainChanged(DomainEvent e) - { - // get the data from this event - ... - } - } -</pre> -</font> - -<p> -A domain listener may either listen for the duration of a DataStore session or may be transient, to be used for -a receiving data from a particular command. For example, after calling <code>DataStore.command</code>, which returns -the status of the command instance, a listener can be added as follows: -</p> -<font color='#4444CC'> -<pre> - ... - MyDomainListener listener = new MyDomainListener(shell); - `ds.getDomainNotifier().addDomainListener(listener); - listener.setStatus(status); - ... -</pre> -</font> -</body> -</html>
\ No newline at end of file diff --git a/rse/doc/org.eclipse.dstore.doc.isv/guide/Communications.html b/rse/doc/org.eclipse.dstore.doc.isv/guide/Communications.html deleted file mode 100755 index 3cad8e804..000000000 --- a/rse/doc/org.eclipse.dstore.doc.isv/guide/Communications.html +++ /dev/null @@ -1,159 +0,0 @@ -<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> -<html> -<head> -<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=UTF-8"> -<META HTTP-EQUIV="Content-Style-Type" CONTENT="text/css"> -<meta name="copyright" content="Copyright (c) IBM Corporation and others 2000, 2006. This page is made available under license. For full details see the LEGAL in the documentation book that contains this page." > -<title>RSE Model</title> -<link rel="stylesheet" type="text/css" HREF="../book.css"> -</head> - -<body> -<h1>DataStore Communications</h1> -<p> -Communication in the DataStore is asynchronous and symmetric. Commands sent and results received are all represented in the same form, -<a href="DataElements.html">DataElements</a> and the underlying means of transmitting this information is basically the same for each. -When a command is issued, it gets queued and then later routed to the appropriate <b>miner</b> where it gets executed. -A miner returns results by updating the DataStore repository with information. Like commands, these -results are queued and then later notifications are sent out to any listener that requires the results. -</p> -<p> -The asynchronous routing of data and commands between a client and the tools is made possible by threads, called <i>handlers</i>. There are two -types of handlers - a <a href="#commandhandlers">Command Handler</a> and an <a href="#updatehandlers">Update Handler</a>. Each handler thread contains a queue -of data that needs to be transmitted and each periodically communicates the data contained in it's queue. -</p> - -<h2><a name="commandhandlers">Command Handlers</a></h2> -<p> -The job of the Command Handler is to route commands to the miners. There are two types of command handlers. -</p> - -<h3><a name="clientcommandhandler">Client Command Handler</a></h3> -<p> -The <b>Client Command Handler</b> is a command handler responsible for transmitting its queue of DataStore commands across a network to -the server DataStore. This handler encapsulates the communication of DataStore client data to a DataStore server. The Client Command Handler -interfaces the DataStore communication layer, where its queue of commands gets serialized into XML before being sent over a TCP/IP socket -to the server. -</p> - -<h3><a name="servercommandhandler">Server Command Handler</a></h3> -The <b>Server Command Handler</b> is a command handler responsible for directly routing the DataStore commands in its queue to the appropriate -miner(s) depending on the command. - -<h2><a name="updatehandlers">Update Handlers</a></h2> -<p> -The job of the Update Handler is to notify the client that some results have been received or changed. There are two types of -update handlers. -</p> - -<h3><a name="clientupdatehandler">Client Update Handler</a></h3> -<p> -The <b>Client Update Handler</b> is an update handler responsible for sending out domain notifications for each unit of data -contained in its queue. -</p> - -<h3><a name="serverupdatehandler">Server Update Handler</a></h3> -<p> -The <b>Server Update Handler</b> is an update handler responsible for transmitting its queue of DataStore objects across a network to -the client DataStore. This handler encapsulates the communication of DataStore server data to a DataStore client. The Server Update Handler -interfaces the DataStore communication layer, where its queue of data gets serialized into XML before being sent over a TCP/IP socket -to the client. -</p> - -<p> -Communication between a client and tools may either occur locally and remotely depending on how the -user chooses to connect to the DataStore. The client interface and the server tooling are the same regardless of -whether the DataStore is standalone or client/server based. The communication differences are encapsulated by -the DataStore handlers. -</p> - -<h2>Standalone Local DataStore</h2> -<p> -Locally, the DataStore may be used standalone such that all communication through the DataStore goes directly to between the <b>miners</b> -and the client, all running within the same process. In this case, there is only a single DataStore and no communication goes -over the network. For its handlers, the local DataStore uses a <b>Client Update Handler</b> and a <b>Server Command Handler</b>. -</p> - -<img src="images/local.jpg" alt="Local DataStore Eclipse" border="0"> - -<p> -In the above dialog, the path of commands to the tools is shown with solid lines, while the path of data to client is shown with dotted lines. - -<ol> -<li> -In RSE, a subsystem calls a DataStore command API to issue a command. -</li> -<li> -The command is then queued in the <b>Server Command Handler</b>. -</li> -<li> -The Server Command Handler gets the command from the queue, determines which miner should run it, and passes the command into that miner. -</li> -<li>The miner then executes the command and produces results by calling DataStore object creation methods. When the resulting objects are created, -the DataStore queues them in the <b>Client Update Handler</b>. -</li> -<li> -The Client Update Handler gets the data from the queue and sends out a domain notification for each data object in the queue. -</li> -<li> -A domain listener for the RSE subsystem receives the notification and then uses the result data to update the UI. -</li> -</ol> -</p> - -<h2>Client/Server DataStore</h2> -<p> -In the remote case, a DataStore client is part of the Eclipse process, while the DataStore server is run -in a separate process on a remote host. Information is transferred between the two DataStore repositories over -a TCP/IP socket. Any data that is created or changed on either the client or the server is asynchronously -propagated over to the other side via serialization/deserialization of the delta. - -Like in the standalone case, the client DataStore uses a <b>Client Update Handler</b>, but instead of using -a Server Command Handler it uses a <b>Client Command Handler</b>. The server DataStore uses a <b>Server Update Handler</b> -and a <b>Server Command Handler</b>. -</p> - -<img src="images/remote.jpg" alt="Remote DataStore Eclipse" border="0"> - -<ol> -<li> -In RSE, a subsystem calls a DataStore command API to issue a command. -</li> -<li> -The command is then queued in the <b>Client Comamnd Handler</b>. -</li> -<li> -The Client Command Handler gets the command from the queue and, via the communication layer, transmits it to the server DataStore. -The communication layer on the client serializes the DataStore respository objects that make up the command and sends that -serialization over a socket to the server. -</li> -<li> -The communication layer on the server deserializes the socket data and creates DataStore objects in the DataStore repository. -Those command objects are added it to the <b>Server Command Handler</b> queue. -</li> -<li> -The Server Command Handler gets the command from the queue, determines which miner should run it, and passes the command into that miner. -</li> -<li> -The miner then executes the command and produces results by calling DataStore object creation methods. When the resulting objects are created, -the DataStore queues them in the <b>Server Update Handler</b>. -</li> -<li> -The Server Update Handler gets the results from the queue and transmits them, via the DataStore communicate layer, to the client DataStore. -The communication layer on the server serializes the DataStore objects from the queue and sends that serialization over a socket -to the client. -</li> -<li> -The communication layer on the client deserializes the socket data and creates DataStore objects in the DataStore respository. -Those results are added to the <b>Client Update Handler</b> queue. -</li> -<li> -The Client Update Handler gets the data from the queue and sends out a domain notification for each data object in the queue. -</li> -<li> -A domain listener for the RSE subsystem receives the notification and then uses the result data to update the UI. -</li> -</ol> -</p> -</body> -</html>
\ No newline at end of file diff --git a/rse/doc/org.eclipse.dstore.doc.isv/guide/DataElements.html b/rse/doc/org.eclipse.dstore.doc.isv/guide/DataElements.html deleted file mode 100755 index 50eb1468e..000000000 --- a/rse/doc/org.eclipse.dstore.doc.isv/guide/DataElements.html +++ /dev/null @@ -1,206 +0,0 @@ -<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> -<html> -<head> -<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=UTF-8"> -<META HTTP-EQUIV="Content-Style-Type" CONTENT="text/css"> -<meta name="copyright" content="Copyright (c) IBM Corporation and others 2000, 2006. This page is made available under license. For full details see the LEGAL in the documentation book that contains this page." > -<title>RSE Model</title> -<link rel="stylesheet" type="text/css" HREF="../book.css"> -</head> - -<body> -<h1><a name="dataelements">DataElements</a></h1> -<p> -All information in the DataStore repository is stored in the form of <b>DataElements</b>. DataElements are objects -that have attributes and may contain other DataElements. The attributes of a DataElement are stored as an array of -strings. A particular attribute is retrieved by calling <code>getAttribute(</code><i>attribute index</i><code>)</code>. -A particular attribute is set by calling <code>setAttribute(</code><i>attribute index</i><code>, </code><i>attribute value</i><code>)</code>. -The attribute indices that can be used are as follows: -<table> -<tr><td><b>Attribute</b></td><td><b>Description</b></td></tr> -<tr><td><code>A_TYPE</code></td><td>Attribute indicating the type of object. The type can be used to indicate the type of an instance of data, a descriptor, a relationship or a commnad.</td></tr> -<tr><td><code>A_NAME</code></td><td>Attribute indicating the name of object.</td></tr> -<tr><td><code>A_VALUE</code></td><td>Attribute indicating the more information about that object</td></tr> -<tr><td><code>A_SOURCE</code></td><td>Attribute indicating source information about an object, if applicable</td></tr> -<tr><td><code>A_REF_TYPE</code></td><td>Attribute indicating whether the object is a normal object ("value"), a spirit ("spirit"), or a reference to another DataElement ("reference"). In the DataStore, a reference to another DataElement is represented with a DataElement. For more information on spirit elements, see <a href="MemoryManagement.html">Memory Management in DataStore</a> </td></tr> -<tr><td><code>A_ID</code></td><td>The unique ID of a DataElement.</td></tr>. -</table> -</p> -<p> -Rather than representing different types of objects as different classes, the type attribute of a DataElement -indicates its type. There are two general categories of DataElements. There are schema elements, <A href="#descriptors">descriptors</a>, and instances of -those schema elements, <a href="#instances">instances</a>. -</p> - -<h2><a name="descriptors">Descriptors</a></h2> -<p> -A descriptor is a DataElement that describes some type of object. The <code>A_TYPE</code> attribute of a descriptor indicates what type of -descriptor it is. The <code>A_NAME</code> attribute of a descriptor identifies the type that the descriptor describes. -</p> -<p> -A descriptor may be of one of the following types: -</p> -<table> -<tr><td><code>T_OBJECT_DESCRIPTOR</code></td><td>Describes a type of object</td></tr> -<tr><td><code>T_RELATION_DESCRIPTOR</code></td><td>Describes a type of relationship that may exist between two DataElements.</td></tr> -<tr><td><code>T_COMMAND_DESCRIPTOR</code></td><td>Describes a type of command</td></tr> -</table> - -<h3><a name="objectdescriptors">Object Descriptors</a></h3> -<p> -<b>Object descriptors</b> describe the different types of data that can be represented in the DataStore repository. Object descriptors -can describe types of object instances as well as other types of object descriptors. Each object descriptor is related to other object, -relationship and command descriptors. -</p> - -<h3><a name="relationdescriptors">Relation Descriptors</a></h3> -<p> -<b>Relation descriptors</b> describe the different types of relationships that can be represented in the DataStore repository. Relation -descriptors describe types of relationships between object instances, object descriptors, command instances and command descriptors. -</p> - -<h3><a name="commanddescriptors">Command Descriptors</a></h3> -<p> -<b>Command descriptors</b> describe the different types of commands that can be executed on an object in the DataStore repository. -In the DataStore schema, object descriptors are related to command descriptors to indicate that an object instance of a certain type can -have the described command run on it. Command descriptors are always contained by the object descriptors they are associated with. The -<code>A_SOURCE</code> attribute of a command descriptor indicates which miner(s) may execute an instance of such a command. -</p> - -<p> -These three types of objects are used to define the DataStore schema. Instances of relation descriptors are used to define -relationships between descriptors in the schema. -</p> - - -<h2><a name="instances">Instances</a></h2> -<p> -An instance object is a DataElement that is an instance of a descriptor. An instance may either by an object, a -relation or a command. An instance uses its descriptor's <code>A_NAME</code> attribute as its <code>A_TYPE</code> attribute. -</p> - -<h3><a name="objects">Objects</a></h3> -<p> -<b>Objects</b> are instances of <b>object descriptors</b>. Objects are used to the represent the external or internal -entities that are being interacted with. An instance object can be related in a certain way to another type of -instance object if its object descriptor has the same kind of relationship to the other object's object descriptor. -An instance object may be associated with a particular command if its object descriptor is associated with the command descriptor -for that command. -</p> - -<h3><a name="relations">Relations</a></h3> -<p> -<b>Relations</b> are instances of <b>relation descriptors</b>. A relation is really a typed reference to another object. Relations -may exist from one object to another if the schema indicates that the object descriptor for the first object may have a relationship -of that type to the other object's descriptor. Relations are used to describe the relationship between two instances, the -relationship between two descriptors and the relationship between an instance and a descriptor. A relation is able to reference -another element by storing the other element's <code>A_ID</code> attribute in its <code>A_SOURCE</code> attribute. If a relation object -needs to be dereferenced, it uses this attribute to query the DataStore for the object being referenced. -</p> -<p> -A relation is typically represented by having an instance object DataElement contain a relation DataElement. -There are two types of relationships between elements that are implicit. These are the <i>contains</i> and -the <i>parent of</i> relationships. If an element is directly contained within another element, the -relationship between those two elements is implied to be <i>contains/parent of</i> relationships. -</p> - -<h3><a name="commands">Commands</a></h3> -<p> -<b>Commands</b> are instances of <b>command descriptors</b>. A command is always associated with an instance object such that -the command is to be performed on that object. The object associated with a command is referred to as the <i>subject</i> of -the command. Only a command that has a command descriptor that is related to the object descriptor of the subject may be -constructed. A command object is constructed when the DataStore method <code>command()</code> is called. The command is -created with a reference to the subject, an optional set of arguments, also instance objects, and a status object instance, used -to indicate the state of the command. The tree of elements for a command is communicated, via the DataStore comm layer, to -the appropriate miner(s), where it is interpreted and executed. -</p> -<p> -The structure of a command looks like the following: -</p> -<ul> -<li>Command - <ul> - <li>subject - a reference to the instance that this command applies to</li> - <li>arg 1 - an optional argument represented as a DataElement</li> - <li>...</li> - <li>arg n - an optional argument represented as a DataElement</li> - <li>status - element that represents the current status of a command</li> - </ul> -</li> -</ul> - -<p> -As an example, suppose the DataStore is being used for browsing a filesystem. The filesystem entities and how to interact -with the filesystem needs to be defined in the schema. The following descriptors could be used to describe this. -</p> - -<ul> -<li>Object Descriptors - <ul> - <li>"generic file object" - describes a generic file system object</li> - <li>"file" - describes a file object</li> - <li>"folder" - describes a folder object</li> - </ul> -</li> -<li>Relation Descriptors - <ul> - <li>"contains" - represents the containment relationship between two objects</li> - <li>"abstracts" - represents a derives relationship between two object descriptors</li> - <li>"abstracted by" - represents an inherits relationship between two object descriptors</li> - </ul> -</li> -<li>Command Descriptors - <ul> - <li>"query" - a command to list the contents of a folder</li> - <li>"rename" - a command to rename a file or folder</li> - <li>"delete" - a command to delete a file or folder</li> - <li>"create" - a command to create a new file or folder from an existing folder</li> - </ul> -</li> -</ul> - -<p> -Now that all the required descriptors are defined, relations between descriptors are needed. Note that the -symbol "->" implies a "contains" relationship and "IO()" implies an instance of a specified descriptor. -</p> - -<ul> -<li>"generic file object" - <ul> - <li>->"rename"</li> - <li>->"delete"</li> - <li>->IO("abstracts")->"folder"</li> - <li>->IO("abstracts")->"file"</li> - </ul> -</li> -<li>"folder" - <ul> - <li>->"create"</li> - <li>->"query"</li> - <li>->IO("abstracted by")->"generic file object"</li> - <li>->IO("contains")->"generic file object"</li> - </ul> -</li> -<li>"file" - <ul> - <li>->IO("abstracted by")->"generic file object"</li> - </ul> -</li> -</ul> - -<p> -DataStore schemas are created by the DataStore <b>miners</b>. Each tool contributes it's -own schema to the DataStore schema, referencing descriptors of other schemas, such -that one tool can contribute to another tool. All the command descriptors that are -contributed by a miner are expected to be handled by the contributing miner. Whenever -a miner creates a new command descriptor, the <code>A_SOURCE</code> attribute indicates -to the DataStore that an instance of that command should be routed to that miner when -it's issued. -<p> - -<p> -See the section, <a href="Miners.html">Miners</a> to find out how miners contribute schemas -and execute commands. -</p> -</body> -</html>
\ No newline at end of file diff --git a/rse/doc/org.eclipse.dstore.doc.isv/guide/Extending.html b/rse/doc/org.eclipse.dstore.doc.isv/guide/Extending.html deleted file mode 100755 index a136e4b6d..000000000 --- a/rse/doc/org.eclipse.dstore.doc.isv/guide/Extending.html +++ /dev/null @@ -1,18 +0,0 @@ -<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> -<html> -<head> -<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=UTF-8"> -<META HTTP-EQUIV="Content-Style-Type" CONTENT="text/css"> -<meta name="copyright" content="Copyright (c) IBM Corporation and others 2000, 2006. This page is made available under license. For full details see the LEGAL in the documentation book that contains this page." > -<title>Tutorials</title> -<link rel="stylesheet" type="text/css" HREF="../book.css"> -</head> - -<body bgcolor="#ffffff"> -<h1>Extending and Using the DataStore</h1> -<p> -This section describes the basic steps required for extending the server DataStore with -a DataStore miner and how to interact with the miners from an RSE subsystem. -</p> -</body> -</html>
\ No newline at end of file diff --git a/rse/doc/org.eclipse.dstore.doc.isv/guide/MemoryManagement.html b/rse/doc/org.eclipse.dstore.doc.isv/guide/MemoryManagement.html deleted file mode 100644 index 3d4874181..000000000 --- a/rse/doc/org.eclipse.dstore.doc.isv/guide/MemoryManagement.html +++ /dev/null @@ -1,68 +0,0 @@ -<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> -<html> -<head> -<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=UTF-8"> -<META HTTP-EQUIV="Content-Style-Type" CONTENT="text/css"> -<meta name="copyright" content="Copyright (c) IBM Corporation and others 2006. This page is made available under license. For full details see the LEGAL in the documentation book that contains this page." > -<title>RSE DataStore Memory Management</title> -<link rel="stylesheet" type="text/css" HREF="../book.css"> -</head> - -<body> -<h1><a name="dataelements">Memory Management in DataStore</a></h1> -<p> -Since RSE version 7.0 a substantial design change has been made to the DataStore that significantly reduces the memory footprint of the -DataElements in high-use, long up-time situations. A problem that was identified was that in the DataStore, DataElements were -rarely being destroyed - only when the files they represented were themselves deleted. When directories in the file system were explored, -DataElements were being created to represent the files in the directories, but these DataElements were cached and never -removed from the cache. Therefore, the number of DataElements in the DataStore was always increasing. With no opportunity -to clear the cache or remove elements, the memory usage of the server continued to grow boundlessly. -</p> -<h2><a name="spirit">A solution - Spirit DataElements</a></h2> -<p> -The solution to the problem of an ever-growing set of DataElements was simple - provide a mechanism of removing "old" -DataElements and thus shrinking the set. Since server memory real-estate comes at a much higher premium, the focus here -is on server-side memory reduction. The assumption then, is that DataElements in the DataStore will always remain in -memory on the client, but that in the mirror-image DataStore that resides on the server, DataElements can be removed. -</p> -<p> -Formerly, the RSE ran under the assumption that the client and server DataStores mirrored each other. The new -implementation has a server DataStore tree that is only a subset of all the elements in the client tree (because -some elements get removed.) In order to accommodate this, a new boolean member variable was added to the DataElement -class called "isSpirit". When this variable is set to true it means different things on the client and server. On the -server, a "spirit" DataElement means the element is treated in much the same way as a "deleted" element. At the first -opportunity, the element is purged from the DataStore and garbage collected by the JVM - freeing up memory. On the client, -a "spirit" element means that that particular DataElement's counterpart has been made a spirit; thus the client "knows" -that its twin element on the server side has either been deleted, or is about to be deleted. -</p> -<h2><a name="disconnecting">Disconnecting "old" DataElements:</a></h2> -<p> -How is it determined when to mark a given DataElement as a spirit? It was decided that the decision to this would be -left to clients of the DataStore (the miners), rather than to the DataStore itself. This was done for the purposes of -granularity: some individual miners may not want DataElements to be ever purged, some might want only specific elements, -etc. As an example, the UniversalFileSystemMiner employs the FileClassifier to classify files returned from a directory -query, and after each file has been classified, the DataStore's disconnectObject() method is called on the DataElement -representing that file, setting the stage for its becoming a spirit. -</p> -<h2><a name="queue">Controlling the queue of DataElements:</a></h2> -<p> -A new class, the DataElementRemover, running in its own thread, maintains a queue of objects that were passed into -DataStore's disconnectObject() method; each object is stored in the queue along with the time it was added. The -DataElementRemover is configurable by two command-line options: -DSPIRIT_EXPIRY_TIME=x and -DSPIRIT_INTERVAL_TIME=y; -where x and y are integers representing a number of seconds. Every y seconds, the queue checks its elements and "makes -spirit" all those that are older than x seconds. The DataElement is then refreshed, and the change propagated to the -client. On the server side, the DataElement is deleted at the first opportunity. -</p> -<h2><a name="feature">Turning on the feature:</a></h2> -<p> -On the client side, this feature is always "on". It is the server which is configured to do or not to do the spirit -DataElement behaviour. This way, backwards compatibility is maintained - if a new client connects to an old server, or a -server with spirit turned off, the client detects this and operates as before. If an old client connects to a new server -with spirit turned on, the server detects that the client does not have spirit capability and behaves as it did before. -</p> -<p> -To turn on the spirit feature on the server side, one needs to include the command-line option -DDSTORE_SPIRIT_ON=true. -The server scripts have been packaged in order to do this by default. -</p> -</body> -</html> diff --git a/rse/doc/org.eclipse.dstore.doc.isv/guide/Miners.html b/rse/doc/org.eclipse.dstore.doc.isv/guide/Miners.html deleted file mode 100755 index 525a9d793..000000000 --- a/rse/doc/org.eclipse.dstore.doc.isv/guide/Miners.html +++ /dev/null @@ -1,142 +0,0 @@ -<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> -<html> -<head> -<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=UTF-8"> -<META HTTP-EQUIV="Content-Style-Type" CONTENT="text/css"> -<meta name="copyright" content="Copyright (c) IBM Corporation and others 2000, 2006. This page is made available under license. For full details see the LEGAL in the documentation book that contains this page." > -<title>RSE Model</title> -<link rel="stylesheet" type="text/css" HREF="../book.css"> -</head> - -<body> -<h1>Miners</h1> -<p> -<b>Miners</b> are remote tooling extensions to the DataStore. Each miner describes the model -that it works with as well as the commands associated with the model that it implements. Each -miner is responsible for extending the DataStore schema and providing implementations for -commands that it defines. -</p> -<p> -All miners are derived from the abstract class <code>Miner</code>. To write a miner, the -following APIs need to be implemented: -</p> -<pre> - public abstract void extendSchema(DataElement schemaRoot); - public abstract DataElement handleCommand(DataElement theCommand); -</pre> -<p> -The first method, <code>extendSchema</code>, is implemented by a miner to contribute the types of objects, relationships and commands that -it deals with. The second method, <code>handleCommand</code>, is implemented by a miner so that it can execute the commands it defines. -</p> - -<h2>Extending the Schema</h2> -<p> -A miner extends the DataStore schema by populating the <i>schemaRoot</i> with <a href="DataElements.html#descriptors">descriptors</a>. -The DataStore repository tree is structured so that there is a single node where schema descriptors reside. All -<a href="DataElements.html#objectdescriptors">object descriptors</a> and <a href="DataElements.html#relationdescriptors">relation descriptors</a> -are created under this schema root. <a href="DataElements.html#commanddescriptors">Command descriptors</a> are created under the -object descriptors that they apply to. Each miner contributes to this global DataStore schema, so each may also extend or leverage the -information from another miner's schema. -</p> -<p> -A miner implements <code>extendSchema(DataElement)</code> to add new descriptors to the DataStore schema. If a miner creates representations -of objects that are not already represented by some other miner's schema, then it needs to define descriptors for those new types of objects. -Sometimes new relationship types also need to be defined by a miner for its particular model. In order for a miner to be interacted with, -via <code>handleCommand</code>, it needs to define command descriptors for object descriptors in the schema. The code below illustrates the -typical structure of an <code>extendSchema</code> implementation: -</p> - -<font color='#4444CC'> -<pre> - public void extendSchema(DataElement schemaRoot) - { - // create object descriptors - DataElement myObjectType1 = createObjectDescriptor(schemaRoot, "my object type 1"); - DataElmeent myObjectType2 = createObjectDescriptor(schemaRoot, "my object type 2"); - DataElement myObjectContainerType = createObjectDescriptor(schemaRoot, "my object container"); - - // create relation descriptors - DataElement myRelationType = createRelationDescriptor(schemaRoot, "my relation type"); - - // create command descriptors - createCommandDescriptor(myObjectType1, "My Command 1", MY_COMMAND_1); - createCommandDescriptor(myObjectType2, "My Command 2", MY_COMMAND_2); - createCommandDescriptor(myObjectContainerType, "Query", MY_QUERY); - - // establish relationships between object types - createReference(myObjectType1, myObjectType2, myRelationType); // myObjectType1 instances can be associated with myObjectType2 instances by myRelationType - createReference(myObjectContainerType, myObjectType1); // myObjectContainerType instances can contain myObjectType1 instances - createReference(myObjectContainerType, myObjectType2); // myObjectContainerType instances can contain myObjectType2 instances - - ... - } -</pre> -</font> - -<p> -The DataStore does not enforce that instance element trees are structured in the manner that the schema describes so the -establishing of relationships between object types, as done in this example, is unnecessary as a miner knows its own -model, since it defined it. But by convention, it is a good thing to describe a model with those relationships explicitly stated -because other miners or client tools may want to leverage or extend the model for their own purposes. -</p> - - -<h2>Handling Commands</h2> -<p> -The <code>handleCommand</code> method is called by the <a href="Communications.html#servercommandhandler">Server Command Handler</a> -if the descriptor for a command instance is associated with a particular miner. When this is called, it is up to the miner implementation -to interpret and execute the command. -</p> -<p> -A <a href="DataElements.html#commands">Command instance</a> is a tree of <a href="DataElements.html">DataElements</a> representing the -command, the subject of the command, additional arguments to the command and the status of the command. The way this is normally interpretted -by a miner to mean <i>perform the specified command on the subject using the specified arguments. Change the status to be "done" when the -operation is complete.</i>. -</p> -<p> -The base miner class provides APIs to assist a miner implementation in extracting information from -a command tree. The method <code>getCommandName(DataElement)</code> is used to extract the -name of the command, <code>getCommandStatus(DataElement)</code> returns the status element of -the command, and <code>getCommandArgument(DataElement, int)</code> returns an argument at the -specified index. The first argument is always the subject. The code below illustrates -the typical structure of a <code>handleCommand</code> implementation. -</p> - -<font color='#4444CC'> -<pre> - public DataElement handleCommand(DataElement theElement) - { - String name = getCommandName(theElement); - DataElement status = getCommandStatus(theElement); - DataElement subject = getCommandArgument(theElement, 0); - - if (name.equals(MY_COMMAND_1)) - { - handleMyCommand1(subject, arg1,...,argn, status); - } - ... - status.setAttribute(DE.A_NAME, "done"); - _dataStore.refresh(status); - } -</pre> -</font> -<p> -The results of a command may be returned in a variety of ways, depending on its -purpose. One thing that is always returned is the status object. -</p> -<p> -Think of the status object as the return value of a method. The status object needs to be set to "done" -whenever a command is complete but it may also optionally contain results in the form -of DataElements. If a command is requesting transient information about something, then -the status object could be populated with the results. -</p> -<p> -Each miner has read and write access to the entire DataStore tree. If desired a miner -can modify that tree as a result of a command. For example, a miner used for browsing -a file system might populate the subject, a folder object, with other folder and file -objects, rather than transiently via the status object. In this way, a miner caches -data and expands the data available to the DataStore repository in response to user -requests. -</p> -</body> -</html>
\ No newline at end of file diff --git a/rse/doc/org.eclipse.dstore.doc.isv/guide/ServerSide.html b/rse/doc/org.eclipse.dstore.doc.isv/guide/ServerSide.html deleted file mode 100755 index 5ec50b7b9..000000000 --- a/rse/doc/org.eclipse.dstore.doc.isv/guide/ServerSide.html +++ /dev/null @@ -1,36 +0,0 @@ -<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> -<html> -<head> -<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=UTF-8"> -<META HTTP-EQUIV="Content-Style-Type" CONTENT="text/css"> -<meta name="copyright" content="Copyright (c) IBM Corporation and others 2000, 2006. This page is made available under license. For full details see the LEGAL in the documentation book that contains this page." > -<title>Tutorials</title> -<link rel="stylesheet" type="text/css" HREF="../book.css"> -</head> - -<body bgcolor="#ffffff"> -<h1>Extending the Server-side</h1> -<p> -This section describes the basic steps needed to extend the server side tooling using <b>Miners</b>. -</p> -<ol> -<li> -Write a new <a href="Miners.html">DataStore miner</a> by extending the <b>Miner</b> class. -</li> -<li> -Put the compiled miner class on the host, preferably in jar form -</li> -<li> -Register the new miner so that it gets loaded when the server DataStore is connected to. This may be done -by adding the miner's qualified classname to the file <i>minerFile.dat</i>. Alternatively, an additional <i>minerFile.dat</i> -file can be used to supply the classname. -</li> -<li> -Update the classpaths for the server side so that the new miner class can be loaded by the -DataStore. This will vary depending on how the DataStore server is started up. If a startup -script is used, then you could update the classpath specified in the script or the system classpath -could be updated. -</li> -</ol> -</body> -</html>
\ No newline at end of file diff --git a/rse/doc/org.eclipse.dstore.doc.isv/guide/images/arch.jpg b/rse/doc/org.eclipse.dstore.doc.isv/guide/images/arch.jpg Binary files differdeleted file mode 100755 index c52bd9ff9..000000000 --- a/rse/doc/org.eclipse.dstore.doc.isv/guide/images/arch.jpg +++ /dev/null diff --git a/rse/doc/org.eclipse.dstore.doc.isv/guide/images/local.jpg b/rse/doc/org.eclipse.dstore.doc.isv/guide/images/local.jpg Binary files differdeleted file mode 100755 index 806c24f43..000000000 --- a/rse/doc/org.eclipse.dstore.doc.isv/guide/images/local.jpg +++ /dev/null diff --git a/rse/doc/org.eclipse.dstore.doc.isv/guide/images/remote.jpg b/rse/doc/org.eclipse.dstore.doc.isv/guide/images/remote.jpg Binary files differdeleted file mode 100755 index 0829df309..000000000 --- a/rse/doc/org.eclipse.dstore.doc.isv/guide/images/remote.jpg +++ /dev/null diff --git a/rse/doc/org.eclipse.dstore.doc.isv/guide/overview.html b/rse/doc/org.eclipse.dstore.doc.isv/guide/overview.html deleted file mode 100755 index 3f2aa1a07..000000000 --- a/rse/doc/org.eclipse.dstore.doc.isv/guide/overview.html +++ /dev/null @@ -1,67 +0,0 @@ -<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> -<html> -<head> -<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=UTF-8"> -<META HTTP-EQUIV="Content-Style-Type" CONTENT="text/css"> -<meta name="copyright" content="Copyright (c) IBM Corporation and others 2000, 2006. This page is made available under license. For full details see the LEGAL in the documentation book that contains this page." > -<title>Remote System Explorer Overview</title> -<link rel="stylesheet" type="text/css" HREF="../book.css"> -</head> - -<body bgcolor="#ffffff"> -<h1>DataStore Overview</h1> -<p> -The RSE uses the concept of <b>subsystems</b> as a common abstraction for remote tooling. Subsystems provide -public interfaces that are called when some remote tool or resource needs to be communicated with. As long as -the appropriate public interfaces are implemented, the means of communicating with these remote tools and resources -is up to the developer of the subsystem. Whatever that might be, some kind of communication layer is required -to access tools on the host. One such means that is used by existing RSE Subsystems and can be reused is the -DataStore framework. -</p> -<p> -The <b>DataStore</b> communications framework is used to provide remote access and tooling for the Remote Systems Explorer. -It is a communications layer, in-memory data repository and a pluggable tooling framework. While Eclipse provides -the ability for local tools to plug into the Eclipse workbench, DataStore provides the ability to integrate -remote tools into the Remote Systems Explorer. When implementing subsystem APIs, a particular implementation -may provide remote function by leveraging DataStore. -</p> - -<img src="images/arch.jpg" alt="DataStore and it's relationship to RSE and Eclipse" border="0"> - -<p> -In an RSE subsystem, the goal of the DataStore is to provide the bridge to tools and resources on the host. -To interact with a remote tool, a DataStore client communicates over a network with a DataStore server. Data and -commands are transferred between the client and server via the DataStore communication layer. Information -that is communicated between each side is kept in memory with the DataStore repository. Both the client and server DataStores -have this repository and it is the responsibility of the DataStore communication layer to keep the contents -of each of these repositories in sync. All the DataStore data on the server side is replicated to the client and -and vice versa. -</p> -<p> -The DataStore framework is generic in the sense that it can be used to facilitate any kind of remote tooling. There are -no specialized APIs or artifacts that are geered towards a particular use. How DataStore is used is determined by the -tool extensions, <a href="Miners.html">Miners</a>. <a href="Miners.html">Miners</a> are typically either adapters to -tools on the host or are tools themselves. These extensions determine the meaning of data used to represent objects, -relationships and the commands that can be issued on the represented objects. <a href="Miners.html">Miners</a> shape the -DataStore by contributing <a href="Schemas.html">schemas</a> to the pool of information in a DataStore repository. -Because the client and server DataStore repositories are synchronized, the DataStore clients -have access to the miner <a href="Schemas.html">schemas</a> and, using that information, they are able to communicate with the tools on the host. -Because the server has access to those miner <a href="Schemas.html">schemas</a>, each <a href="Miners.html">Miners</a> may also communicate with -other <a href="Miners.html">Miners</a> on the host in the same way a client can. -</p> -<p> -A Filesystem miner can shape the DataStore by contributing a <a href="Schemas.html">schema</a> that -describes file systems and how they should be interacted with. The <a href="Schemas.html">schema</a> could describe -files, folders, properties of files and relationships between them as well as commands for querying folders or renaming files. -An RSE subsystem, can then provide browsing capabilities to a remote file system by sending commands -via the DataStore client to the Filesystem Miner on the host. Another <a href="Miners.html">miner</a> can -contribute its own <a href="Schemas.html">schema</a> or extend the existing Filesystem Miner <a href="Schemas.html">schema</a> -to leverage or contribute to the existing file system tool. -</p> -<p> -This guide explains all underlying -artifacts and model of the DataStore, its relationship to RSE, and highlights the -important APIs available for your use. -</p> -</body> -</html>
\ No newline at end of file diff --git a/rse/doc/org.eclipse.dstore.doc.isv/notices.html b/rse/doc/org.eclipse.dstore.doc.isv/notices.html deleted file mode 100755 index 6c70b9c62..000000000 --- a/rse/doc/org.eclipse.dstore.doc.isv/notices.html +++ /dev/null @@ -1,22 +0,0 @@ -<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
-<html>
-<head>
-
-<meta name="copyright" content="Copyright (c) IBM Corporation and others 2000, 2006. This page is made available under license. For full details see the LEGAL in the documentation book that contains this page." >
-
- <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
- <LINK REL="STYLESHEET" HREF="book.css" CHARSET="ISO-8859-1" TYPE="text/css">
- <title>Legal Notices</title>
-</head>
-<body>
-
-<h3>
-<a NAME="Notices"></a>Notices</h3>
-<p>
-The material in this guide is Copyright (c) IBM Corporation and others 2000, 2006.
-</p>
-<p>
-<a href="about.html">Terms and conditions regarding the use of this guide.</a>
-</p>
-</body>
-</html>
\ No newline at end of file diff --git a/rse/doc/org.eclipse.dstore.doc.isv/options.txt b/rse/doc/org.eclipse.dstore.doc.isv/options.txt deleted file mode 100755 index fcb8f7dbd..000000000 --- a/rse/doc/org.eclipse.dstore.doc.isv/options.txt +++ /dev/null @@ -1,25 +0,0 @@ --charset "iso-8859-1" --sourcepath "../org.eclipse.dstore.core/src -;../org.eclipse.dstore.extra/src" --d reference/api --classpath @rt@ --breakiterator --use --splitIndex --windowtitle "Remote System Explorer DataStore API Specification" --doctitle "Remote System Explorer DataStore API Specification" --header "<b>Remote System Explorer DataStore</b><br>Release 1.0" --bottom '<font size="-1"><p><a href="{@docRoot}/../misc/api-usage-rules.html">Guidelines for using DataStore APIs</a>.</p></font>' --link http://java.sun.com/j2se/1.4.2/docs/api --linkoffline ./../../../org.eclipse.platform.doc.isv/reference/api @javadoc.link.location@/platform/reference/api/ --link http://bundles.osgi.org/javadoc/r4 - -org.eclipse.dstore.core -org.eclipse.dstore.core.client -org.eclipse.dstore.core.java -org.eclipse.dstore.core.miners.miner -org.eclipse.dstore.core.model -org.eclipse.dstore.core.server -org.eclipse.dstore.core.util -org.eclipse.dstore.core.util.ssl -org.eclipse.dstore.extra
\ No newline at end of file diff --git a/rse/doc/org.eclipse.dstore.doc.isv/plugin.properties b/rse/doc/org.eclipse.dstore.doc.isv/plugin.properties deleted file mode 100755 index b9113ccc8..000000000 --- a/rse/doc/org.eclipse.dstore.doc.isv/plugin.properties +++ /dev/null @@ -1,14 +0,0 @@ -############################################################################### -# Copyright (c) 2000, 2006 IBM Corporation 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: -# IBM Corporation - initial API and implementation -############################################################################### - -# NLS_MESSAGEFORMAT_VAR -pluginName=RSE DStore ISV Documentation -providerName=Eclipse.org diff --git a/rse/doc/org.eclipse.dstore.doc.isv/plugin.xml b/rse/doc/org.eclipse.dstore.doc.isv/plugin.xml deleted file mode 100755 index 51854ca97..000000000 --- a/rse/doc/org.eclipse.dstore.doc.isv/plugin.xml +++ /dev/null @@ -1,9 +0,0 @@ -<?xml version="1.0" encoding="UTF-8"?> -<plugin> - - <extension point="org.eclipse.help.toc"> - <toc file="toc.xml" primary="true"/> - <index path="index/"/> - </extension> - -</plugin> diff --git a/rse/doc/org.eclipse.dstore.doc.isv/reference/.cvsignore b/rse/doc/org.eclipse.dstore.doc.isv/reference/.cvsignore deleted file mode 100644 index eedd89b45..000000000 --- a/rse/doc/org.eclipse.dstore.doc.isv/reference/.cvsignore +++ /dev/null @@ -1 +0,0 @@ -api diff --git a/rse/doc/org.eclipse.dstore.doc.isv/reference/placeholder.txt b/rse/doc/org.eclipse.dstore.doc.isv/reference/placeholder.txt deleted file mode 100644 index 89b1c1c77..000000000 --- a/rse/doc/org.eclipse.dstore.doc.isv/reference/placeholder.txt +++ /dev/null @@ -1 +0,0 @@ -A nearly empty file used to force the creation of the containing folder.
\ No newline at end of file diff --git a/rse/doc/org.eclipse.dstore.doc.isv/toc.html b/rse/doc/org.eclipse.dstore.doc.isv/toc.html deleted file mode 100755 index a410f833c..000000000 --- a/rse/doc/org.eclipse.dstore.doc.isv/toc.html +++ /dev/null @@ -1,18 +0,0 @@ -<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
-
-<html>
-<head>
- <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
- <META HTTP-EQUIV="Content-Style-Type" CONTENT="text/css">
- <LINK REL="STYLESHEET" HREF="book.css" TYPE="text/css">
- <title>RSE DataStore developer information</title>
-</head>
-
-<body>
-<h1>Using the RSE DataStore for Remote Communications</h1>
-This section provides information for tool developers who wish to
-add server-side tooling capabilities. Using the RSE DataStore tooling
-communication framework, server-side extensions can be written. The Remote System Explorer can be
-extended to interface the new server-side extensions.
-</body>
-</html>
\ No newline at end of file diff --git a/rse/doc/org.eclipse.dstore.doc.isv/toc.xml b/rse/doc/org.eclipse.dstore.doc.isv/toc.xml deleted file mode 100755 index 66c07c020..000000000 --- a/rse/doc/org.eclipse.dstore.doc.isv/toc.xml +++ /dev/null @@ -1,30 +0,0 @@ -<?xml version="1.0" encoding="UTF-8"?>
-<?NLS TYPE="org.eclipse.help.toc"?>
-
-<toc label="RSE DStore Developer Guide">
- <topic label="Guide">
- <topic label="DataStore Overview" href="guide/overview.html">
- <topic label="DataStore Artifacts" href="guide/Artifacts.html" />
- <topic label="DataStore Communications" href="guide/Communications.html" />
- <topic label="DataElements and the DataStore Model" href="guide/DataElements.html" />
- <topic label="Memory Management of DataElements" href="guide/MemoryManagement.html" />
- <topic label="Miners" href="guide/Miners.html" />
- </topic>
- <topic label="Extending and Using the DataStore" href="guide/Extending.html">
- <topic label="Extending the Server-side" href="guide/ServerSide.html" />
- <topic label="Communicating with the Server-side" href="guide/ClientSide.html" />
- </topic>
- <anchor id="guide_additions"/>
- </topic>
- <topic label="Reference">
- <topic label="DataStore API Reference">
- <topic label="org.eclipse.dstore.core.model" href="reference/api/org/eclipse/dstore/core/model/package-summary.html" />
- <topic label="org.eclipse.dstore.core.client" href="reference/api/org/eclipse/dstore/core/client/package-summary.html" />
- <topic label="org.eclipse.dstore.core.server" href="reference/api/org/eclipse/dstore/core/server/package-summary.html" />
- <topic label="org.eclipse.dstore.core.util" href="reference/api/org/eclipse/dstore/core/util/package-summary.html" />
- <topic label="org.eclipse.dstore.core.miners.miner" href="reference/api/org/eclipse/dstore/core/miners/miner/package-summary.html" />
- </topic>
- <anchor id="reference_additions"/>
- </topic>
- <topic label="Legal" href="notices.html"/>
-</toc>
|
