Hi James,<br><br>Based on your feedback, I've changed to wording for the write_file() entry to the following:<br><p><i><b>The following simple write_file() method shows how both metadata and
files are written. write_file() must point to a physical file. This
file reference can be created in several ways:
</b></i></p>
<ol><li><i><b> Your program can explicitly create a file in write_file() and write to it. 
</b></i></li><li><i><b> You can download or save a file to a particular location and
then change the self._jobject.file_path variable (as the Read activity
does).</b></i></li></ol>However, I still am hesitant about writing metadata to a physical file if the activity doesn't use a physical file for anything else. At a conceptual level, this approach (to me) seems like it would confuse what is metadata and what is actual file data and puts unnecessary burden on a developer to keep track. Ideally, I'm wondering if there should just be an abstraction to an activity as having both metadata and file data and it is the prerogative of the developer to put stuff where it is appropriate (without the two necessarily interacting, as is now the case where you have to put metadata about an activity in a physical file if none exists). If I were to write a wrapper for datastore to build this abstraction, it would look something like:<br>
<br>class ActivityInstanceInDatastore:<br>    def write_metadata_entry(self, key, value)<br>    def read_metadata_entry(self, key)<br>    def write_file(self, file_path, stuff_to_write)<br>    def read_file(self, file_path)<br>
<br>These exist already to some extent in datastore, but it seems from this thread that the functional behavior doesn't yet follow a strict pattern of behavior. Also, there is the issue of activities having multiple data files (eg. for a file diff activity) which I believe is dealt with by setting special metadata mappings to keep track of all the files (correct me if I'm wrong). <br>
<br>Practically, I understand there will be many cases where the current setup won't be a huge deal. However, it will be a big problem when people develop activities that may or may not be associated with a data file at different times. For example, I could envision a music activity that has specific preset music settings (such as frequency settings, volume, etc.) as well as optional files that are being manipulated by the activity. If the user doesn't have a data file open, then you would just want to save metadata, but then later if the user does open an audio file, then you will want to have both metadata and physical data. Rather than keeping track of what state you are in, it seems more coherent and natural that the developer only worries about specific calls to write metadata when he wants to write metadata (like volume and playback settings) and only worries about file-specific calls when he wants to manipulate files. <br>
<br>Thanks<br><br><br>Faisal<br><br><br><br><div class="gmail_quote">On Mon, Jun 16, 2008 at 1:35 PM, James Simmons <<a href="mailto:jim.simmons@walgreens.com">jim.simmons@walgreens.com</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Faisal,<br>
<br>
Look at the code for the Read activity.  It never creates a Journal entry itself.  What it does is to resume from a directory entry created by downloading a PDF through the Browse activity or perhaps one copied from a USB key using the Journal activity.  So there *is* a file in the Journal entry, but there is no desire to update that file.  If you have that situation you can save metadata without writing a file, just like Read does.  No special code is needed.<br>

<br>
Metadata not being preserved across a reboot is a known bug.  Metadata not being preserved for entries on SD cards and USB keys is a *feature*.  These devices are not considered part of the Journal proper, although the current UI makes them *look* like they should be.  There are good reasons to treat files on USB devices differently from Journal entries.  I understand that the USB and SD parts of the Journal may be given a different look to avoid this kind of confusion.  I don't know when this will happen.  The developers who could do this have a lot on their plates. <br>

If you have no data file, it would be a good idea to use a file to store persistent information about options, etc.  The only time you wouldn't do that is when you have a file in the datastore that must not be modified, as in the Read activity.<br>
<font color="#888888">
<br>
James Simmons</font><div><div></div><div class="Wj3C7c"><br>
<br>
<br>
Faisal Anwar wrote:<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi James,<br>
<br>
Thanks for the feedback. I had two follow up questions for you or others who are in the know with datastore:<br>
<br>
1. You said: 'However, if your application is like Read, Read Etexts, or View Slides, which are always resumed from existing Journal entries, there is no need to write a file.  You can still save metadata, even if you don't write a file.'<br>

<br>
</blockquote>
<br>
<br>
</div></div></blockquote></div><br>