Some editor notes closed.

diff --git a/helm/papers/calculemus-2003/hbugs-calculemus-2003.tex b/helm/papers/calculemus-2003/hbugs-calculemus-2003.tex
index 2b43e84e473e691f668efc98e68ee1194e781e7a..1ec47373fabc87be1c051a557b25b20bf17d9beb 100644 (file)
--- a/helm/papers/calculemus-2003/hbugs-calculemus-2003.tex
+++ b/helm/papers/calculemus-2003/hbugs-calculemus-2003.tex
@@ -143,8 +143,7 @@
   domain.
 }
 
   domain.
 }
 

-\section{An \hbugs{} Bird'S Eye View\ednote{Zack: sono in vena di boiate
-stasera!}}
+\section{An \hbugs{} Bird'S Eye View}

 \label{architecture}
   \myincludegraphics{arch}{t}{8cm}{\hbugs{} architecture}{\hbugs{} architecture}
 
 \label{architecture}
   \myincludegraphics{arch}{t}{8cm}{\hbugs{} architecture}{\hbugs{} architecture}
 


@@ -177,8 +176,7 @@ stasera!}}
     \wss{} interfaces}
 
     Using W3C's terminology \cite{ws-glossary}, clients act both as \ws{}
     \wss{} interfaces}
 
     Using W3C's terminology \cite{ws-glossary}, clients act both as \ws{}

-    providers and requesters, see \ednote{Zack: va bene "see"?, "cfr" credo sia
-    solo italiano ...} Fig. \ref{interfaces}.
+    providers and requesters, see Fig. \ref{interfaces}.

     They act as providers for the broker (to receive hints)
     and as requesters (to submit new status). Clients
     additionally use broker service to know which tutors are available and to
     They act as providers for the broker (to receive hints)
     and as requesters (to submit new status). Clients
     additionally use broker service to know which tutors are available and to


@@ -262,9 +260,6 @@ stasera!}}
 
 \section{Implementation's Highlights}
 \label{implementation}
 
 \section{Implementation's Highlights}
 \label{implementation}

-\ednote{Zack: l'aspetto grafico di questa parte e' un po' peso, possiamo
-aggiungere varie immagini volendo, e.g.: schema dei thread di un tutor, sample
-code di un tutor generato automaticamente}

 In this section we present some of the most relevant implementation details of
 the \hbugs{} architecture.
 
 In this section we present some of the most relevant implementation details of
 the \hbugs{} architecture.
 


@@ -381,9 +376,7 @@ the \hbugs{} architecture.
     broker to send him an unique identifier and its base URI as a
     \ws{}. After the registration, the client can use broker's
     \texttt{List\_tutors} method to get a list of available tutors.
     broker to send him an unique identifier and its base URI as a
     \ws{}. After the registration, the client can use broker's
     \texttt{List\_tutors} method to get a list of available tutors.

-    Eventually\ednote{CSC: Vuoi veramente dire eventually qui? Zack: si, prima o
-    poi lo faranno ...} the
-    client can subscribe to one or more of these using broker's
+    Eventually the client can subscribe to one or more of these using broker's

     \texttt{Subscribe} method. Clients can also unregister from brokers using
     \texttt{Unregister\_client} method.
 
     \texttt{Subscribe} method. Clients can also unregister from brokers using
     \texttt{Unregister\_client} method.
 


@@ -425,7 +418,7 @@ the \hbugs{} architecture.
 
     Consulting the \musings{} registry, the tutor\ednote{CSC: ma \'e vero o
     stai delirando? Zack: e' vero, non ti fidi? :-) Up to delay di rete
 
     Consulting the \musings{} registry, the tutor\ednote{CSC: ma \'e vero o
     stai delirando? Zack: e' vero, non ti fidi? :-) Up to delay di rete

-    ovviamente ...} is able to know, at each time,
+    ovviamente ... CSC: ma a che serve???} is able to know, at each time,

     which \musings{} are in execution on which tutor. This peculiarity is
     exploited by the broker on invocation of Status method. Receiving a new
     status from the client implies indeed that the previous status no longer
     which \musings{} are in execution on which tutor. This peculiarity is
     exploited by the broker on invocation of Status method. Receiving a new
     status from the client implies indeed that the previous status no longer


@@ -465,7 +458,8 @@ the \hbugs{} architecture.
     resources.\ednote{CSC: A cosa dobbiamo questa architettura delirante? Se non
     ricordo male al problema dell'uccisione dei thread. Ora o si spiega
     il motivo di questa architettura o si glissa/bluffa. Zack: cosa ti sembra
     resources.\ednote{CSC: A cosa dobbiamo questa architettura delirante? Se non
     ricordo male al problema dell'uccisione dei thread. Ora o si spiega
     il motivo di questa architettura o si glissa/bluffa. Zack: cosa ti sembra

-    delirante? che i thread vengono uccisi? ... non mi e' molto chiaro ...}
+    delirante? che i thread vengono uccisi? ... non mi e' molto chiaro ...
+    CSC: la motivazione per avere due thread always running e non due}

 
     This architecture turns out to be scalable and allows the running threads
     to share the cache of loaded (and type-checked) theorems.
 
     This architecture turns out to be scalable and allows the running threads
     to share the cache of loaded (and type-checked) theorems.