[Registry-dev] Typed properties [was: Suggested Registry changes/improvements]

[Glen Daniels]

+1, Jonathan, totally agree with your reasoning here.  A property is a 
(small-r) resource in the REST sense of being able to PUT and DELETE it 
via the HTTP interface, but it's not a (big-R) Resource in our registry 
"community-enabled" sense.

--Glen

Jonathan Marsh wrote:
> +1 to the first approach.  See below:
> 
> Jonathan Marsh - http://www.wso2.com - http://auburnmarshes.spaces.live.com
>  
> 
>> -----Original Message-----
>> From: registry-dev-bounces at wso2.org [mailto:registry-dev-
>> bounces at wso2.org] On Behalf Of Chathura C. Ekanayake
>> Sent: Thursday, November 08, 2007 9:53 AM
>> To: registry-dev at wso2.org
>> Subject: [Registry-dev] Suggested Registry changes/improvements
>>
>>
>> Below are the changes and improvements suggested in the discussion with
>> Glen and Jonathan.
>>
> ...
> 
>> 3) Properties with arbitrary content
>>
>> Currently properties of resources can only store strings as their
>> values. Glen suggests that we should be able to associate any arbitrary
>> content with resources as properties. There are two possible ways to do
>> that. One method is to change the data model of the registry, so that
>> we
>> can store blobs as resource properties. Then we can associate a media
>> type with properties to specify whether it is a string or binary
>> content.
> 
> I like the approach of having a properties with names, values, and media
> types.  Simple, clean, very powerful, and allows us to do some nice things
> to display the property in the UI: e.g. a JPEG can show a preview and an
> upload button to change it, a simple string can be displayed directly with
> an inline edit field for quick entry, and XML document might link to an XML
> editing view, an HTML document might link to a rich text editor, etc.
> 
> I also think we might want to define a couple of our own special "media
> types" for this, such as a simple length-limited string from a text/plain
> resource, a url, or an epr.  The UI could adapt intelligently to the user's
> intention if we had these types along with the traditional media types.
> 
>> Second method is to store the content of the property as a normal
>> resource in the registry and store the URL of that resource as the
>> property value. Then, when ever we look up a property we should
>> determine whether it is a string or a URL. If it is URL, we should get
>> the content of the corresponding resource and return it as the property
>> value. This look up functionality can either be implemented in the
>> registry or in the product that uses arbitrary property contents. This
>> method does not require changes in the registry data model.
> 
> I don't like this.  If it's a normal resource, we should allow comments,
> tags, ratings, children, etc.  What's then the point then of distinguishing
> the "property" children of a resource from the "resource" children of the
> resource?  And you'd still need a type mechanism to differentiate from
> simple string properties and paths, which is equal in complexity to the
> first option.
> 
>> Comments...
>>
>> Thanks,
>> Chathura
>>
>>
>>
>> _______________________________________________
>> Registry-dev mailing list
>> Registry-dev at wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/registry-dev
> 
> 
> _______________________________________________
> Registry-dev mailing list
> Registry-dev at wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/registry-dev
>