On Jun 1, 2009, at 1:34 PM, Aristedes Maniatis wrote:
> * it seems simpler (that way it works like all other elements in the
> map)
>
> * we can extend it: perhaps I didn't explain well enough. Say we
> want to allow some MapEntryProperties to propagate to the client in
> ROP and others not to (for security or speed reasons). Then we'll
> need a new field in MapEntryProperty as "availableOnClient".
>
> * we might like to type properties. Say a user wants to create
> "maxCacheTime" as a MapEntryProperty with an int value in seconds.
> They have code which does clever things in expiring caches for that
> ObjEntity. But we need a way to ensure that particular
> MapEntryProperty is stored as an int and they can define that in the
> UI.
I don't really like complexity of a type system here. This feature has
to be simple. Supporting a type system for properties looks like an
overkill for what we are trying to do here. Although I am with you on
#2 - we need a way to filter properties from the client. So I guess I
am ok with some sort of Property/Info object, as long as the simpler
String API wrapper is available to the end user.
Andrus
This archive was generated by hypermail 2.0.0 : Mon Jun 01 2009 - 08:03:16 EDT