Hi Tomeu,<br><br>Thanks so much for the clarifications. I understand now the abstraction intended for metadata accessed through DSMetadata and DSObject and will try to write that up a little more forcefully. I guess the main thing I was concerned about was having a consistent and lasting interface to the datastore (which can certainly be implemented in the form of a dictionary if that is most appropriate). I hope this abstraction will hold moving forward so that activity developers are confident that their hooks in to datastore will work with the same behavior over time (this is part of the purpose of the documentation I'm working on). <br>
<br>With regards to the lower level DBus calls in datastore and elsewhere, what I'm really looking out for is what levels of the tech stack an activity developer will need to learn to build a fairly robust and complex activity. Of course, for some things lower level Dbus calls may be unavoidable, but I'm assuming that there should be a substantive interface in python that abstracts away the Dbus functionality for most developers. As I go through more of the code in datastore, presence, and elsewhere, I'll try to identify cases where perhaps a low-level Dbus call could be abstracted to some standard python calls. <br>
<br><br>Faisal<br><br><br><div class="gmail_quote">On Wed, Jun 25, 2008 at 4:28 AM, Tomeu Vizoso <<a href="mailto:tomeu@tomeuvizoso.net">tomeu@tomeuvizoso.net</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;">
Hi Faisal, some answers below:<br>
<br>
2008/6/24 Faisal Anwar <<a href="mailto:fanwar@mediamods.com">fanwar@mediamods.com</a>>:<br>
<div class="Ih2E3d">><br>
> ?? Is there a specific reason why there isn't a "set()" method in the<br>
> datastore.DSMetadata class? Shouldn't people be given standard accessors and<br>
> mutators to work with this code. This is especially confusing because it<br>
> seems there is presently a "get()" method, but the set() method does not<br>
> exist (so the abstraction is completely different based on whether you are<br>
> getting or setting data). d<br>
<br>
</div>That class is to be used in the same way as dictionaries in python, so<br>
the API mimics that. By implementing __getitem__, __setitem__ and<br>
get(), the user can do the following:<br>
<br>
obj.metadata['my-property'] = 'blah blah'<br>
print obj.metadata['my-property']<br>
print obj.metadata.get('my-property', 'N/A')<br>
<div class="Ih2E3d"><br>
> ?? Several things that are currently documented at<br>
> <a href="http://wiki.laptop.org/go/Low-level_Activity_API#Keeping_and_Resuming" target="_blank">http://wiki.laptop.org/go/Low-level_Activity_API#Keeping_and_Resuming</a> are<br>
> outdated. Specifically, it says datastore.create() returns the object_id.<br>
> That's wrong, it returns the actual DSObject. Furthermore, it says there are<br>
> methods called datastore.update and datastore.get_properties, but they don't<br>
> exists.<br>
<br>
</div>That page documents the low level API that can be used by all<br>
activities, no matter in which language are written. sugar.datastore<br>
is a higher level API only available to python activities. See here<br>
for the D-Bus API of the datastore:<br>
<br>
<a href="http://dev.laptop.org/git?p=projects/datastore;a=blob;f=src/olpc/datastore/datastore.py" target="_blank">http://dev.laptop.org/git?p=projects/datastore;a=blob;f=src/olpc/datastore/datastore.py</a><br>
<div class="Ih2E3d"><br>
> ?? The deletion/destruction of datastore activities seems to be a little<br>
> confusing. In particular, there is a datastore.delete() method and there is<br>
> also a DSObject.destroy() method. Why doesn't datastore.delete() simply call<br>
> the destroy() method in its code so that any files associated with the<br>
> deleted datastore object are also removed. Given that a warning is thrown<br>
> telling the developer that an object is deleted without directly calling<br>
> DSObject.destroy() (it is called indirectly through the __del__ method, but<br>
> why not have things more explicit?), I'm not sure why this isn't just done<br>
> programmatically. Is there ever a reason why one woul perform a delete() on<br>
> an object without doing the functionality in DSObject.destroy() and are any<br>
> of these reasons compelling enough that we should keep the delete() and<br>
> destroy() methods as they are now?<br>
<br>
</div>Well, datastore.delete() instructs the datastore to delete the object<br>
from its persistent storage. DSObject.destroy() is intended to be<br>
called when the user stops needing the transient instance that<br>
represents the persistent object.<br>
<br>
This is similar to DB programming with SQL in procedural languages,<br>
deleting the resultset object is not the same as deleting the rows<br>
that are contained in that resultset.<br>
<div class="Ih2E3d"><br>
> Other questions may come up as people work more on this documentation. In<br>
> the meantime, I'd greatly appreciate any feedback on the existing work and<br>
> also any answers to the questions above.<br>
<br>
</div>Nice work, more questions welcome.<br>
<br>
Regards,<br>
<font color="#888888"><br>
Tomeu<br>
</font></blockquote></div><br>