1 |
|
|
2 |
|
Many hypermedia systems place each document and link in the custody |
3 |
|
of one server, rendering it unusable when connectivity fails. |
4 |
|
For example, on the web, when connection to a server fails, |
5 |
|
links to documents on this server can generally not be followed. |
6 |
|
Open Hypermedia Systems such as Microcosm [ref] store links |
7 |
|
in *linkbases* on specific servers. In the Xanadu 88.1 design [ref], |
8 |
|
documents and links can be cached, but still have a 'home' server |
9 |
|
on which a 'master' copy is located. [XXX look more into it, correct xu terms] |
10 |
|
|
11 |
|
Such a system does not lend itself well to a world |
12 |
|
where servers fail, where clients are not 'always on,' and |
13 |
|
where documents regularly move from computer to computer in the form |
14 |
|
of email attachments. In a system where documents and links |
15 |
|
belong to one server, in a disconnected state documents |
16 |
|
cannot be retrieved and links cannot be followed. |
17 |
|
[XXX this isn't precise-- it's not true in this form] |
18 |
|
When documents are forwarded per email or downloaded from the Web today, |
19 |
|
links generally break. |
20 |
|
|
21 |
|
We propose a system implementing Xanalogical storage [ref Ted] |
22 |
|
based on global, location-independent identifiers, where |
23 |
|
document contents are named by cryptographical hashes [ref GUID paper]. |
24 |
|
Assuming an index of all documents and links |
25 |
|
on the local computer and all systems that can be reached through |
26 |
|
the currently available network connections. Since no centralized |
27 |
|
scheme can scale to such an index of "everything," keeping one |
28 |
|
for the public Internet requires a decentralized, |
29 |
|
self-organizing distributed system (the IPTPS'03 definition |
30 |
|
of "peer-to-peer" [ref]). |
31 |
|
|
32 |
|
We propose to use this same system for publication on the 'net |
33 |
|
and storage on a local computer. This means that |
34 |
|
when a local document is published or a public document |
35 |
|
is saved locally, it retains its identifier; as long as a |
36 |
|
document is also accessible through the network, keeping |
37 |
|
a local copy is merely an efficiency measure (keeping |
38 |
|
a permanent cache). Obviously, in such scheme, as long as link |
39 |
|
remains accessible, it never breaks just because the documents |
40 |
|
it refers to are moved to a different location. |
41 |
|
|
42 |
|
The Squirrel system [ref] is a peer-to-peer network of shared |
43 |
|
browser caches, where a web page can be retrieved from |
44 |
|
any computer in a local network that has a copy in its cache. |
45 |
|
Our distributed index for document and link retrieval would |
46 |
|
have this as a natural side-effect, except |
47 |
|
that it would also extend any data that has been permanently |
48 |
|
downloaded on one of the network's computers. |
49 |
|
|
50 |
|
A system as we propose would necessiate deep changes in applications. |
51 |
|
As Vitali [ref Versioning hypermedia] notes, any implementation |
52 |
|
of Xanalogical storage necessiates this, as "[n]o approximate, |
53 |
|
good-enough solutions" for the management of global identifiers |
54 |
|
"can conceivably be considered acceptable in this case." [#]_ |
55 |
|
As such, we are cannot meet the minimum definition of an |
56 |
|
open hypermedia system, as given by Davis et al [ref]: |
57 |
|
We do impose storage of markup on applications and we cannot |
58 |
|
generally use data created by tools that are not aware of our system. |
59 |
|
|
60 |
|
... |
61 |
|
|
62 |
|
|
63 |
|
|
64 |
|
.. [#] We have built a system for editing Xanalogical text |
65 |
|
in a non-aware editor such as ``emacs``, attempting to |
66 |
|
determine the user's changes through structure matching [ref]. |
67 |
|
This seems to work reasonably well for insertions, |
68 |
|
removals and rearrangements, but is hopeless if the user |
69 |
|
uses copy&paste between arbitrary documents. |
70 |
|
|
71 |
|
|
72 |
|
|
73 |
|
|
74 |
|
|
75 |
|
|
76 |
|
|
77 |
|
Stuff not yet located in the article :-) |
78 |
|
======================================== |
79 |
|
|
80 |
|
(remove-at-will: There are two kinds of mobility related to hypermedia use:) |
81 |
|
|
82 |
|
In today's networked world, data moves freely between computers: |
83 |
|
Text is copied from one document to another, documents |
84 |
|
are moved between folders, |
85 |
|
copied from one computer to another, sent by email, |
86 |
|
independently modified on two computers simultaneously, |
87 |
|
published on a server, moved to a different server, downloaded |
88 |
|
by a client. Yet, every time content is moved, links and references to it break |
89 |
|
in popular hypermedia systems. |
90 |
|
|
91 |
|
Also, computers are used by people who are increasingly mobile |
92 |
|
[psych mobility research -paper], on global range. |
93 |
|
There are even prospects of interplanetary use of digital communications |
94 |
|
[cerf:internetplantary_internet]. This sets challenges for the "freedom" |
95 |
|
(referring to 1.) of data movement, as there are limits to the reach and |
96 |
|
performance of the networks (incl-from:antont->ohs-talk/disconnected?). |
97 |
|
Problems include disconnections (due to e.g. breakages), ... |
98 |
|
|
99 |
|
Thirdly, the amount of internetworked computers will increase rapidly, as |
100 |
|
new kinds of devices are being connected via different channels to the |
101 |
|
unifying Internet, creating heavy masses of usage. When pieces of content |
102 |
|
are tied to a location, a lot of traffick (tiivistyy) near a single point |
103 |
|
of |
104 |
|
failure. Therefore the common URL addressing on the Web may fail ... |
105 |
|
OTOH, yet: server downtimes etc. |
106 |
|
|
107 |
|
Research has been done in a number of areas to alleviate this problem. |
108 |
|
There are a number of proposals for sharing a web browser's cache |
109 |
|
between users [squirrel]. |
110 |
|
... |
111 |
|
Thompton and De Roure [ref ht'01] propose a peer-to-peer system |
112 |
|
for discovering cached web resources in a mobile, disconnected setting, |
113 |
|
available on the client or other systems connected to it through |
114 |
|
ad-hoc local networks (e.g., wireless). |
115 |
|
|
116 |
|
... |
117 |
|
|
118 |
|
We aim for a solution that will support mobility for all of a user's data |
119 |
|
(everything they'd store in their personal directory). Any pieces of text, |
120 |
|
any document and any collection of documents should be easy to move |
121 |
|
to a different computer, and after modifying the data on both systems, |
122 |
|
it should be easy to bring the two copies back in sync. |
123 |
|
|
124 |
|
Another motivation (right?) for the data sharing / data mobility is |
125 |
|
collaboration. Within an organization or a project group, there often is a |
126 |
|
shared file system, e.g. a file server in the local network, so that |
127 |
|
different people do not need their personal copies of the data but can work |
128 |
|
(synchronously) on the same items. Often, however, especially when |
129 |
|
crossing organizationary boundaries there is no access each-others' |
130 |
|
filesystems even though data is shared. In actual collaboration, where |
131 |
|
several individuals work on the same items -- possibly at the sametime -- |
132 |
|
the data effectually forks. So similarly(?) to the the situation where a |
133 |
|
particular user has data on different computers, data needs to be kept in |
134 |
|
sync when there is collaboration. [cvs, (perforce, ..)] |
135 |
|
|
136 |
|
Our system allows documents and document content to be freely copied |
137 |
|
without breaking links. As long as a link and the documents |
138 |
|
it links are currently accessible, the link can be shown. |
139 |
|
We archieve this by assigning documents and contents permanent, |
140 |
|
location-independent identifiers, and keeping an efficient (hemppah: should |
141 |
|
we emphasize a *distributed* index ?) index of all data by its identity. |
142 |
|
|
143 |
|
---- |
144 |
|
|
145 |
|
This type of system does not lend itself well to a world |
146 |
|
where servers fail and clients are not permanently 'on.' |
147 |
|
Hypermedia functionality ought to be a service at the |
148 |
|
operating system level, usable for organizing all data |
149 |
|
a user stores on their system [ref]. It is of course possible |
150 |
|
for a user to run an own, personal linkbase on their client system, |
151 |
|
|
152 |
|
In an ideal world, when users move documents between computers, |
153 |
|
links would not break, ..., |
154 |
|
different versions of documents could easily be reconciled, |
155 |
|
(file structure would not be lost). We envision a global identifier space, |
156 |
|
where links are created between global identifiers, and whenever |
157 |
|
any two endpoints of a link are known, this link can be shown. |
158 |
|
|
159 |
|
|
160 |
|
|
161 |
|
|
162 |
|
|
163 |
|
|
164 |
|
Xanalogical storage |
165 |
|
=================== |
166 |
|
|
167 |
|
In the xanalogical storage model [cite], pioneered by Project Xanadu [cite], |
168 |
|
links are not between documents, but individual characters. |
169 |
|
When a character is first typed in, it acquires a permanent ID |
170 |
|
("the character 'D' typed by Janne Kujala on 10/8/97 8:37:18"), |
171 |
|
which it retains when copied to a different document, distinguishing |
172 |
|
it from all similar characters typed in independently. |
173 |
|
A link is shown between any two documents containing the characters |
174 |
|
that the link connects. Xanalogical links are external and bidirectional. |
175 |
|
|
176 |
|
In addition to content links, xanalogical storage keeps an index of |
177 |
|
transclusions: identical characters copied into different documents. |
178 |
|
Through this mechanism, the system can show to the user all documents |
179 |
|
that share text with the current document. |
180 |
|
|
181 |
|
|
182 |
|
|
183 |
|
|
184 |
|
|
185 |
|
Idea/Plan |
186 |
|
========= |
187 |
|
|
188 |
|
[Notes for the authors, not part of the final document |
189 |
|
though text may be moved from here to there.] |
190 |
|
|
191 |
|
Whenever a document moves on the current web, links to it break, |
192 |
|
be it from an author's computer to a public server, |
193 |
|
from one server to another, from the server to a client, |
194 |
|
or from one personal computer to another. We subsume |
195 |
|
these forms of movement under the term 'data mobility.' |
196 |
|
|
197 |
|
|
198 |
|
Storm goals/benefits: |
199 |
|
|
200 |
|
- Reliability |
201 |
|
- Append-and-delete-only |
202 |
|
- The same data can be stored in many locations, |
203 |
|
allowing it to be easily reconstructed after failure |
204 |
|
- Versioning: Old versions remain accessible |
205 |
|
- Xanalogical storage |
206 |
|
- If a document is accessible, references to it work |
207 |
|
- Links do not break |
208 |
|
- Easy syncing: |
209 |
|
- Just copy a bunch of blocks |
210 |
|
- Documents can be synced & merged |
211 |
|
- Inter-document structures can be synced & merged |
212 |
|
- Syncing can be done without merging immediately, |
213 |
|
leaving two alternative versions current |
214 |
|
(so e.g. an automated process is entirely possible, |
215 |
|
even when there are conflicts) |
216 |
|
- Versioning |
217 |
|
|
218 |
|
|
219 |
|
Grouped differently, |
220 |
|
|
221 |
|
- Reliability (as above) |
222 |
|
- Usablility in the face of intermittent connectivity |
223 |
|
(includes syncing, finding a document if available...) |
224 |
|
- Xanalogical structure |
225 |
|
(includes versioning, non-breaking links etc.) |
226 |
|
|
227 |
|
Storm limitations/weaknesses: |
228 |
|
|
229 |
|
- what, actually? |
230 |
|
|
231 |
|
antont ponders: for files storm is ok, but how about: |
232 |
|
- irc? (latency?) |
233 |
|
- video? (throughput) |
234 |
|
|
235 |
|
and: |
236 |
|
.. multipoint live video? (both latency and throughput demands) |
237 |
|
|
238 |
|
* does it make sense to think of irc messages, and/or video frames, as |
239 |
|
datablocks .. or what? |
240 |
|
|
241 |
|
|
242 |
|
hemppah's comment on syncing term: |
243 |
|
I'd prefer term 'replication' instead of term syncing, when |
244 |
|
updating data to 'the most recent state'. E.g. Lotus Notes uses |
245 |
|
term replication, when one performs locally made updates into |
246 |
|
a centralized server --> 'used within same system'. Syncing term, however, |
247 |
|
is used when importing/exporting e.g. Nokia Communicator calendar data into/from |
248 |
|
Lotus Notes calendar --> 'used between different systems'. |
249 |
|
|
250 |
|
|
251 |
|
hemppah: worth to mention is that Ray Ozzie is a man behind Lotus Notes and Groove; |
252 |
|
Lotus Notes is based on client-server model and, Groove is based on p2p model --> |
253 |
|
possible direction etc. ? |
254 |
|
|
255 |
|
hemppah: I think we should mention that in Gzz one refer to data in non-hierarchial |
256 |
|
way, where as in Notes (and other systems also, references!!), we must use |
257 |
|
hierarchial way. In Notes most important IDs are: |
258 |
|
1) every document has a unique identifier, which is unique among all replicas |
259 |
|
of database |
260 |
|
2) every document/design element has a identifier, named as noteID, which is unique |
261 |
|
in database, but not among all replicas of database |
262 |
|
3) every view has a unique identifier, which is unique among all replicas of |
263 |
|
database |
264 |
|
4) every database has a replica ID, which identifies database's replicas |
265 |
|
among all databases |
266 |
|
|
267 |
|
So, if we want to refer to a document, we use format: |
268 |
|
|
269 |
|
replicaID/viewID/documentID |
270 |
|
|
271 |
|
Also, we can refer to same document, through *many different* views (analogical to Gzz's dimensions ?): |
272 |
|
notes://<server>/replicaID/viewID1/documentID |
273 |
|
notes://<server>/replicaID/viewID2/documentID |
274 |
|
|
275 |
|
Here's a real example: |
276 |
|
Notes://server/D235632D00313587/38D22BF5E8F088348525JK7500129B2C/REWB3FDE0D53807B67C2256CB50026FCVV |
277 |
|
|
278 |
|
For information about IDs in Notes: |
279 |
|
http://www-12.lotus.com/ldd/doc/tools/c/4.5/api45ug.nsf/85255d56004d2bfd85255b1800631684/00d000c1005800c985255e0e00726863?OpenDocument |
280 |
|
|
281 |
|
In Gzz, however, we don't know the location, we know only the *identity* of data what we are looking for, as follows: |
282 |
|
|
283 |
|
urn-5:FAB3FDE0hgfD5kkjj3807B67C2256CfsdB50026FC51 |
284 |
|
|
285 |
|
Above is not a *correct* urn-5, but very similar to last part of notes' syntax. |
286 |
|
|
287 |
|
<<<<<<< article.rst |
288 |
|
benja's reply: |
289 |
|
Hm. Replication to me means, the same data is kept on multiple |
290 |
|
machines. This is not what we are talking about here: We're talking |
291 |
|
about *different versions* of the same data being kept |
292 |
|
on multiple machines, and occasionally being 'brought into sync' |
293 |
|
with each other. If I send you a draft article and you comment on it, |
294 |
|
and I make changes too, and later I merge the two divergent |
295 |
|
versions back together, 'syncing' seems approximately right, |
296 |
|
but 'replication' seems completely wrong to me. |
297 |
|
|
298 |
|
======= |
299 |
|
(Of course, this is very similar to 'normal' URLs, but our purpose here is to give an example |
300 |
|
of how one refer to a particular data item in colloboration-like tool, like Notes) |
301 |
|
>>>>>>> 1.28 |
302 |
|
|
303 |
|
In Notes, there are servers, which maintain replication of data, opposite to Gzz. What is |
304 |
|
interesting in Notes' replication, is the fact that the replication of database not only |
305 |
|
replicate the *data* but also design of data, which represent the data. |
306 |
|
Worth to mention is also that, even if the data and the design of data (logic etc.) is |
307 |
|
in the *same* (physical) structure, data and design of data is very loosely coupled with |
308 |
|
each other. |
309 |
|
|
310 |
|
Additionally, we should emphatize that how things are going towards non-hierarchical reference models, |
311 |
|
for instance, Notes(hierarchical) and Gzz(non-hierarchical), which both are based on the same |
312 |
|
xanalogical model. |
313 |
|
|
314 |
|
"Usability in the face of intermittent connectivity" is |
315 |
|
more than just mobile applications: It is also copying data |
316 |
|
from one computer to another, where the two computers' |
317 |
|
file systems are not kept in sync through a permanent |
318 |
|
network connection. Hmm, maybe "Usability in the face |
319 |
|
of irregular synchronization" or some such would |
320 |
|
make it clearer? |
321 |
|
|
322 |
|
Ok, let's split that in two: |
323 |
|
|
324 |
|
- Usability in the face of intermittent connectivity |
325 |
|
(we cannot access data stored on the internet) |
326 |
|
- Usability in the face of non-synchronization |
327 |
|
(we can have two independent versions of something |
328 |
|
on two unconnected computers and we can easily |
329 |
|
synchronize the two versions when desired) |
330 |
|
|
331 |
|
|
332 |
|
Thus we have four goals which we must express in the article. |
333 |
|
|
334 |
|
... |
335 |
|
|
336 |
|
so: if there is a permanent network connection, are there reasons for |
337 |
|
using this? (i.e. being out of sync in the first place) |
338 |
|
|
339 |
|
one argument is that there is no such thing as "permanent connection" (in |
340 |
|
a way e.g. a hard disk failure can be thought of as a connection breakdown |
341 |
|
to the data on the drive ?) |
342 |
|
|
343 |
|
but of course synchronization might be the way to approach it, just that |
344 |
|
the irregularity is/may_be caused by the, well, intermittent connectivity? |
345 |
|
|
346 |
|
should the goals be derived from the use cases? or perhaps better looked in |
347 |
|
their light ("niiden valossa") -- take the case of e-mail attachments: |
348 |
|
|
349 |
|
Think of a use case here: email attachments. Between two computers that |
350 |
|
are permanently on the 'net, you *could* replace email attachments by |
351 |
|
"simply" setting up a shared file system between the sender and the |
352 |
|
receiver of the attachment. Then, if the receiver made a modification, |
353 |
|
the sender could even see it immediately. Yet nobody seems to be |
354 |
|
proposing this. The overhead is one thing. Why |
355 |
|
set up and maintain a shared file system for every file you send to |
356 |
|
somebody? Privacy is another. You don't want the sender being able to |
357 |
|
keep track what the receiver does with the document. |
358 |
|
|
359 |
|
... but don't some senders want to be able to track what the receivers do? |
360 |
|
(and thinking of the web: how do you get a "weblog" of a p2p published data?) |
361 |
|
|
362 |
|
And if you don't set up such a file system, but just send an email |
363 |
|
attachment, you've got intermittent synchronization between two |
364 |
|
permanently connected computers. |
365 |
|
|
366 |
|
Another question is, should e-mail attachments be used to share data. |
367 |
|
|
368 |
|
It may be natural when you want one specific person (or small group of people) to look at a document. |
369 |
|
... |
370 |
|
> rsync is an intermittent synchronization solution :-) (it's not about |
371 |
|
> shared file systems, but synchronizing two copies of a file system |
372 |
|
> intermittently). |
373 |
|
|
374 |
|
from:erno |
375 |
|
"firewalls" should be in end systems. ipsec was originally meant to |
376 |
|
be run in transport mode and provide end to end security, to |
377 |
|
work nicely with the ip philosophy. |
378 |
|
| > > i prefer URI:s. |
379 |
|
| i.e. with today's technology, i prefer to put documents on the web or some |
380 |
|
| (other) filesystem within the recipients' reach. |
381 |
|
aren't these two orthogonal? in one case you get a copy of the |
382 |
|
document, in another case you get a (weak) reference to the document. |
383 |
|
i like the "disconnected operation" and loose caching semantics. |
384 |
|
another thing about filesystems, it's not a very precise concept... |
385 |
|
there are several components/aspects. |
386 |
|
(replace "is" with "can be" according to taste:) |
387 |
|
* it's a namespace |
388 |
|
* it's a wire protocol for conducting operations on an object |
389 |
|
* it's an access control system |
390 |
|
* it's a way for people to collaborate |
391 |
|
* it's a locking protocol |
392 |
|
* it's a tracking facility (access_log) |
393 |
|
.... |
394 |
|
> but i still want to have the option of really making sure |
395 |
|
> i have a local copy of a document sitting on my disk, instead |
396 |
|
> of in a local cache that will be flushed before long. |
397 |
|
sure. and i want to have an option, that if any of the four-five machines |
398 |
|
at the studio suffer data loss, work would not be lost, but there's |
399 |
|
backups (also for situations when a machine is off-line etc.), within the |
400 |
|
limited resources of course. |
401 |
|
> -- erno |
402 |
|
~Toni |
403 |
|
> what will people do when they have 3200GB disks and realise |
404 |
|
> they only have useful date to fill 10% of that but would |
405 |
|
> like more reliability? |
406 |
|
OTOH: already in the "grey economy" shares of increasing size are required |
407 |
|
to participate in the network, i.e. you get the movies you want if you |
408 |
|
provide lots of what other's need. and if you don't have any, you're out. |
409 |
|
but this is something gzz want's to avoid, too. |
410 |
|
|
411 |
|
|
412 |
|
|
413 |
|
References: |
414 |
|
|
415 |
|
- CFS (The Chord project's Cooperative File System) |
416 |
|
- Coda ("an advanced network filesystem", http://www.coda.cs.cmu.edu/) |
417 |
|
- The Internet Backplane Protocol |
418 |
|
- Issue about nomadicity, Communications of the ACM (Sep 2001) |
419 |
|
- Note: Support for nomadicity includes scaling of resource |
420 |
|
usage (e.g. bandwidth availability), which we're |
421 |
|
less concerned with here. |
422 |
|
- Future work needed: Currently, the Storm interfaces |
423 |
|
do not provide information about underlying network conditions, |
424 |
|
thus we can't e.g. show to the user what blocks |
425 |
|
are available w/o network lookup and which aren't. |
426 |
|
- Delay-tolerant networks (http://dtnsig.org/) |
427 |
|
- OceanStore |
428 |
|
- Lifestreams, because they are a project believing |
429 |
|
that the network [probably, a server] should hold |
430 |
|
the users' data, not the terminal they access it through |
431 |
|
- Possible reference here: IMAP? |
432 |
|
- The IPTPS'03 call for papers' definition of peer-to-peer |
433 |
|
- P2P Working group: definition of peer-to-peer |
434 |
|
- Hypermedia by coincidence, Thompton et al (HT'01) |
435 |
|
- Freenet, Free Haven et al |
436 |
|
- The pointer problem: CFS, OceanStore |
437 |
|
- A commercial p2p-based collaboration tool: Groove (http://erwin.dstc.edu.au/Herring/GrooveAnalysis-SCI2001.pdf) |
438 |
|
- Hypermedia implementations with non-breaking links: Microcosm, Hyper-G |
439 |
|
- Open Hypermedia, data and link servers? (links not in documents!) |
440 |
|
* term in the hypermedia engineering -book: link management |
441 |
|
- (but not structural computing. hypertext functionality? not really.) |
442 |
|
- Persistent storage: the first 13years (dig bookmark from tolp42:galeon) |
443 |
|
- primitive sync stuff: rsync (ssync?), SyncML? |
444 |
|
- about ibm corporate p2p over http: |
445 |
|
http://www.almaden.ibm.com/cs/people/bayardo/userv/ |
446 |
|
http://www.almaden.ibm.com/cs/people/bayardo/userv/userv.html |
447 |
|
|
448 |
|
P. Druschel and A. Rowstron. PAST: A largescale, persistent peer-to-peer |
449 |
|
storage utility. In IEEE, editor, Eighth IEEE Workshop on Hot Topics in |
450 |
|
Operating Systems (HotOS-VIII). May 20-23, 2001, Schloss Elmau, Germany, |
451 |
|
pages 75-80, 1109 Spring Street, Suite 300, Silver Spring, MD 20910, USA, |
452 |
|
2001. IEEE Computer Society Press. |
453 |
|
|
454 |
|
- Squirrel: a decentralized peer-to-peer web cache |
455 |
|
- Feasibility of a Serverless Distributed File System Deployed on an Existing Set of Desktop PCs |
456 |
|
- Distributed File Systems: Concepts and Example ('de facto article on DFS') |
457 |
|
- Lotus Notes: ftp://ftp.lotus.com/pub/lotusweb/product/notes/G325-2061-00_j.pdf |
458 |
|
- Open Hypermedia in a Peer-to-Peer Context |
459 |
|
- Peer-to-Peer Hypertext |
460 |
|
- Publius and Tangler publishing systems |
461 |
|
- Mnet (ancestor: Mojo Nation), mnet.sourceforge.net |
462 |
|
- Open problems in Data-Sharing Peer-to-Peer Systems |
463 |
|
- Semantic Overlay Networks for P2P systems (a p2p 'version' of Xanalogical transclusions) |
464 |
|
- Farsite Project (similar to CFS, PAST and Oceanstore) |
465 |
|
|
466 |
|
There was a good paper and demo about synchronous collaboration in ht01, but |
467 |
|
is that out of scope here? (see pondering on limitations) |
468 |
|
|
469 |
|
|
470 |
|
Pasted from IRC (Finnish) |
471 |
|
========================= |
472 |
|
|
473 |
<hemppah:#gzz> antont: meidän pitää muuten antaa konkreettisia esimerkkejä |
<hemppah:#gzz> antont: meidän pitää muuten antaa konkreettisia esimerkkejä |
474 |
+artikkelissame colloborationista |
+artikkelissame colloborationista |
475 |
>#gzz> hemppah: toki. use caseja aattelin |
>#gzz> hemppah: toki. use caseja aattelin |