<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p><font size="4">Packaging the data in one file is useful to share
the document. This is something to keep in mind. For DrGeo, it
is XML file. </font></p>
<p><font size="4">I use ReferenceStream for the contents of the
DyboApp. There are both business models and pedagogical contents
to save. The business models are the administration part of the
teacher job. </font></p>
<p><font size="4">The schools, class groups, courses, taught topics,
students, tasks; then the pedagogical documents collected in the
topics. The business model could have been persisted in
traditional data format or DB; but the pedagogical documents are
very heterogeneous and it can be enriched with arbitrary and
heterogeneous DKMs. </font></p>
<p><font size="4">So I use ReferenceStream for the whole, but I try
to circumvent the extent of the tree to be persisted. Each
pedagogical document is saved in its own sub tree, and
referenced as a DiskProxy in the business model tree. The user
data is then distributed in several directories and files, each
with its one data.obj. When you annotated a PDF document, you
also have to deal specifically how to persist the data.</font></p>
<p><font size="4">Object persistence can be tricky, depending on the
object attributes, you may easily find yourself in a situation
where a document subtree also reference another document
subtree. I twisted a bit the ReferenceStream protocol to avoid
persisting some attributes, those can be recomputed at load
time.</font></p>
<p><font size="4">All in all, it is quite ok and very helpful, but
you are never sure of the extent of what is persisted on file.
The resulting object file generated by ReferenceStream contains
some readable information </font><font size="4">(string, class
name) </font><font size="4">which I found helpful to understand
and to debug strange situations.</font></p>
<p><font size="4">I have not yet thought about the class evolution,
it will bring undoubtedly its own problems. I see there is this
SmartReferenceStream to help with class evolution.</font></p>
<p><font size="4">I think ReferenceStream is part of the Squeak
scheme of persistence where an Etoys world is by essence very
heterogeneous. There was also the ImageSegment.</font></p>
<p><font size="4">Hilaire</font></p>
<div class="moz-cite-prefix">Le 18/04/2026 à 10:45, Luciano
Notarfrancesco a écrit :<br>
</div>
<blockquote type="cite"
cite="mid:CAL5GDyrvGZ77YRtK4YYSc5aH0T47aU1zQ+C63eKpaQ1-sAnUxw@mail.gmail.com">
<div>
<div style="font-size:inherit">
<div dir="auto"
style="font-size:inherit;font-style:normal;font-weight:400;letter-spacing:normal;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgba(0,0,0,0);border-color:rgb(0,0,0);color:rgb(0,0,0)">I
do include all samples in the .song files, not only notes.
The .mod files that traditional trackers used also included
the samples (as opposed to .mid MIDI files that only
included notes), and this ensures that they sound correctly
any time you play them because they don’t depend on which
samples are loaded in the tracker.</div>
</div>
<br>
</div>
<div dir="auto">How about you? Why did you choose to use
ReferenceStream for DrGeo? Does it give you any problem when you
add or remove instance variables?</div>
</blockquote>
<pre class="moz-signature" cols="72">--
<a class="moz-txt-link-freetext" href="http://mamot.fr/@drgeo">http://mamot.fr/@drgeo</a></pre>
</body>
</html>