Recent Updates to Sugar Almanac

[Faisal Anwar]

Hi James,

Based on your feedback, I've changed to wording for the write_file() entry
to the following:

*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: *

   1. * Your program can explicitly create a file in write_file() and write
   to it. *
   2. * 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).*

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:

class ActivityInstanceInDatastore:
    def write_metadata_entry(self, key, value)
    def read_metadata_entry(self, key)
    def write_file(self, file_path, stuff_to_write)
    def read_file(self, file_path)

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).

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.

Thanks


Faisal



On Mon, Jun 16, 2008 at 1:35 PM, James Simmons <jim.simmons at walgreens.com>
wrote:

> Faisal,
>
> 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.
>
> 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.
> 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.
>
> James Simmons
>
>
>
> Faisal Anwar wrote:
>
>  Hi James,
>>
>> Thanks for the feedback. I had two follow up questions for you or others
>> who are in the know with datastore:
>>
>> 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.'
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.laptop.org/pipermail/devel/attachments/20080616/ef3f37a9/attachment.html>