[OGo-Discuss] OGo and asterisk, SUMMARY

[Adam Tauno Williams]

> > To be useful though I think the interface would have to be smart enough
> > to provide different properties (for creation) based upon the type of
> > file.  That makes it a bit more complicated.  It seems like it would
> > have to be configurable somewhat like extended attributes are
> > configurable.
> The way this is addressed in zope/plone world is that they separate mime types 
> from keywords. Keywords are tags that are either established by the admin 
> and/or users pending rights allowing users to add this tag to a particular 
> file. 

The list of legitimate attributes should certainly be defined by the
admin.

> So for example creating or uploading a .doc file called testrun the mime type 
> would be .doc (and this is assigned automatically) but the keyword (in this 

".doc" isn't a mime type. (?)  OGo as well stores the "file_type", which
appears to be file extension, for documents.

> So in a journal context if I want a listing of all documents that pertain to X 
> provided that all documents were indeed marked with the keyword X a simple 
> search would provide the listing which then can be saved, linked to or 
> stored.

I don't know.  If a document relates to an object I think it should
really be linked to that object - like with a specific type of
object_link.   Properties seem better suited for 'arbitrary' bits of
information that are related to an item.  

For instance we have a Gtk widget that displays an object link - it
displays the label, comment, and target object_id;  in addition it then
adds summary information depending on the target object type. For
contact, for instance it displays first name, last name, e-mail address,
URL and phone, fax, and mobile numbers.

Properties are another matter.  The application needs to recognize the
property name and know how to display it (and deal with it) - is it a
select box, text, a number, etc...  

I don't know if it is currently possible to search by properties;  all I
know is that they can be loaded and saved (easily).

> From an asterisk perspective pending on where the data is stored, (voice mail 
> for example) keyword may or may not be that useful. 

You'd have to store a voice mail in a project in order for it to have
properties.  Otherwise you can accomplish much the same thing on an IMAP
server using annotations or even just message headers.

> > But if you are automatically importing some content then setting a set
> > of properties is pretty straight forward.
> Ya thats how I understand it.