From 031a8fae69281b31159b236be6b4113c9c74e242 Mon Sep 17 00:00:00 2001 From: =?utf8?q?Zden=C4=9Bk=20=C5=A0ustr?= Date: Thu, 30 Apr 2009 09:31:40 +0000 Subject: [PATCH] Minor language corrections. --- org.glite.lb.doc/src/LBUG-Introduction.tex | 16 ++++++++-------- org.glite.lb.doc/src/versions.tex | 6 +++--- 2 files changed, 11 insertions(+), 11 deletions(-) diff --git a/org.glite.lb.doc/src/LBUG-Introduction.tex b/org.glite.lb.doc/src/LBUG-Introduction.tex index 687e0ea..fb6a3fd 100644 --- a/org.glite.lb.doc/src/LBUG-Introduction.tex +++ b/org.glite.lb.doc/src/LBUG-Introduction.tex @@ -6,7 +6,7 @@ \LB's primary purpose is tracking WMS jobs as they are processed by individual Grid components, not counting on the WMS to provide this data. The information gathered from individual sources is collected, stored in -a database and made available at a single contact point. The user get a +a database and made available at a single contact point. The user gets a complete view on her job without the need to inspect several service logs (which she may not be authorized to see in the entirety or she may not be even aware of their existence). @@ -15,11 +15,11 @@ While \LB keeps track of submitted and running jobs, the information is kept by the \LB service also after the job has been finished (successfully completed its execution, failed, or has been canceled for any reason). The information is usually available several days after the last event -related to the job arrived, to give user an opportunity to check the job +related to the job arrived, to give user an opportunity to check the job's final state and eventually evaluate failure reasons. As \LB collects also information provided by the WMS, the WMS services are -no longer required to provide job-state querying interface. Most of the +no longer required to provide a job-state querying interface. Most of the WMS services can be even designed as stateless---they process a~job and pass it over to another service, not keeping state information about the job anymore. During development and deployment of the first WMS version this @@ -28,7 +28,7 @@ required extent~\cite{jgc}. \LB must collect information about all important events in the Grid job life. These include transitions between components or services, results -of matching and brokerage, waiting in a queue systems or start and end of +of matching and brokerage, waiting in queue systems or start and end of actual execution. We decided to achieve this goal through provision of an API (and the associated library) and @@ -42,12 +42,12 @@ must not prevent (nor block) the instrumented service to perform as usual. An asynchronous model with a clear \emph{asynchronous delivery semantics}, see Sect.~\ref{gathering}, is used to address this issue. -As individual Grid components has only local and transient view about a +As individual Grid components have only local and transient view of a job, they are able to send only information about individual events. This raw, fairly complex information is not a~suitable form to be presented to the user for frequent queries. It must -be processed at the central service and users are presented primarily this -processed form. This form derives its form from the \emph{job state} and its +be processed at the central service and users must be presented primarily with this +processed form. This form is derived from the \emph{job state} and its transition, not from the job events themselves. The raw information is still available, in case more detailed insight is necessary. @@ -63,7 +63,7 @@ for the state information. However, this requirement contains two contradictions: (i)~due to the asynchronous event delivery model, the \LB information may not be up to date and remote queries may lead to unexpected results -(or even inconsistent one---some older information may not be available for +(or even inconsistent ones---some older information may not be available for one query but may arrive before a subsequent query is issued), and (ii)~the dependence on a~remote service to provide vital state information may block the local service if the remote one is not responding. diff --git a/org.glite.lb.doc/src/versions.tex b/org.glite.lb.doc/src/versions.tex index d5a2e45..b67712d 100644 --- a/org.glite.lb.doc/src/versions.tex +++ b/org.glite.lb.doc/src/versions.tex @@ -7,13 +7,13 @@ The Logging and Bookkeeping service (\LB\ for short) was initially developed in the EU DataGrid project\footnote{\url{http://eu-datagrid.web.cern.ch/eu-datagrid/}} as a~part of the Workload Management System (WMS). The development continued in the EGEE, -EGEE-II and EGEE-III projects\footnote{\url{http://www.eu-egee.org/}}, where +EGEE-II and EGEE-III projects,\footnote{\url{http://www.eu-egee.org/}} where \LB became an independent part of the gLite\footnote{\url{http://www.glite.org}} middleware~\cite{glite}. \textbf{Two major versions of \LB service are covered by this document -- \LBold, -that was included in gLite 3.1, and current \LBnew, that is part of gLite 3.2. -Older version of \LB, that appeared in gLite 3.0 become obsolete and is not maintained anymore.} +which was included in gLite 3.1, and current \LBnew that is part of gLite 3.2. +The older version of \LB that appeared in gLite 3.0 became obsolete and is not maintained anymore.} The complete \LB Documentation consists of the following parts: \begin{itemize} -- 1.8.2.3