Bug 224199 - [api] Provide a means of attaching and persisting data as payload to remote objects
Summary: [api] Provide a means of attaching and persisting data as payload to remote o...
Status: NEW
Alias: None
Product: Target Management
Classification: Tools
Component: RSE (show other bugs)
Version: 3.0   Edit
Hardware: All All
: P3 enhancement (vote)
Target Milestone: Future   Edit
Assignee: David McKnight CLA
QA Contact: Martin Oberhuber CLA
URL:
Whiteboard:
Keywords: api
Depends on:
Blocks:
 
Reported: 2008-03-26 16:46 EDT by David McKnight CLA
Modified: 2008-03-27 04:09 EDT (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description David McKnight CLA 2008-03-26 16:46:05 EDT
Some products associate properties with IRemoteFiles.  To do this, they need a mechanism to store info in memory, manage persistence, and handle events that may change the remote file (like rename or move).  Since this may be a reoccuring scenario, RSE could make things easier by handling the properties itself.

My suggestion would be to maintain properties for remote files via property sets, that are stored (in memory) under the remote file subsystem.  RSE could automatically take care of the persistence and could manage any changes that occur due rename, move, etc implicitly.  For API, I could imagine we'd add setProperty(key, value) and getProperty(key) methods to IRemoteFile.

It's possible that we may find it better to abstract this further to allow for other types of remote objects (not just files) to have the property storage capabilities so the scope of this could be expanded.
Comment 1 Martin Oberhuber CLA 2008-03-27 04:09:01 EDT
I would actually like to get this feature much more generic, i.e. ability to attach any kind of extra data as "payload" or meta-info to any kind of remote objects. The payload is maintained on the local system as meta-info but relates to actual remote objects on the remote. There's two distinct points with this:

1.) Subsystems / services need to take care of the payload when renaming or 
    moving remote objects. I'm not sure if we'll be able to provide generic
    support for this in a generic SubSystem. Perhaps each subsystem Impl will
    need some code to support this, so it may be a breaking api change (but
    not necessarily).

2.) Users may want to persist the payload. If generic payload is to be 
    persisted, it needs to provide a means for serializing into a String.
    Property Sets provide this for free, but I'd like to not restrict this to
    Property Sets only. Also, some kind of payload may not need to be persisted.
    One question with persistence is where to actually store the data, and 
    whether some leveling (parent->child) of the metadata should be supported.

Pending investigation, this enhancement may actually be doable with adapters alone, but we'll need some time after 3.0 to find out.

Changed summary, previous value was:
[api] property sets for IRemoteFile as generic means of storing extra properties