Thank you for your reply and I'm sorry about my reply too late.
I understand the point that it is difficult to define ViewType because
there are a variety of runtime environments. I think, however, common
ViewType Enum is very important for the portability of the OpenSocial
application. Well, if there is no common ViewType, a developer must
always have the mapping table with Domain and View in the application.
OpenSocial is the common and standard specification for the social
platform. I think that the enhancement of View Type Enum is proof of
the evolution of OpenSocial Platform. Therefore, the View class is
able to define the function based on ViewType Enum, I think. Of
course, the name of View is also generally used, but I seem ViewType
Enum is more important. This Enum is necessary to develop easily.
Is my idea incorrect?
On Oct 10, 3:11 am, "Kevin Brown" <e...@google.com
> This comes back to a fundamental problem with views -- "type" is largely
> meaningless. There was some attempt at doing semantically meaningful
> attribute addition (http://www.opensocial.org/Technical-Resources/opensocial-spec-v08/gad...
> but we never continued with that.
> There will likely always be an arbitrary number of different views for
> different containers. There are already many different container types
> deployed (or close to being deployed with support announced).
> Consider all the types of places where you might want to run an opensocial
> - Online social networks in the myspace / facebook / orkut mold (most
> closely matches current enum values)
> - Personalized sites like my yahoo, pageflakes, or igoogle
> - Blogs (six apart and blogger are both containers, and google's friend
> connect puts opensocial into even more)
> - Desktop environments
> - Mobile
> I think the enumeration is far too rigid for this.
> I'm a strong proponent of capability based systems for these purposes.
> Currently, developers are simply using the view name that makes sense on the
> container their app is running in (and writing different apps for different
> containers). If we want to improve portability, perhaps we could have
> attributes on the content elements themselves?