[[BackLinksMenu]]

[[TicketQuery(summary=PRO_LIB_REMOTE_OBJECTS_R0, format=table, col=summary|owner|status|type|component|priority|effort|importance, rows=description|analysis_owners|analysis_reviewers|analysis_score|design_owners|design_reviewers|design_score|implementation_owners|implementation_reviewers|implementation_score|test_owners|test_reviewers|test_score|)]]

= Analysis =
^(Give as much as possible of the needed information for designing and implementing the task in the following sections.)^

== Overview ==
^(Provide a brief overview of the whole task in its first revision. Stick to the current revision of the task, but keep an eye to the whole task progress, and stay alert for possible smells.)^

== Task requirements ==
^(List the necessary requirements that the task must fulfill.)^

== Task result ==
^(List the end product of the task (for example "Source code", "Wiki page", etc.))^

== Implementation idea ==
^(Provide some rough implementation idea(s).)^

== Related ==

[wiki:PRO_LIB_CORE_COMMONS]

[wiki:PRO_LIB_MODEL_COMMONS]

[wiki:PRO_LIB_MODEL_PRO_OBJECTS]

== How to demo ==
^(Provide instructions for demonstration of the task.)^

= Design =
^(Describe your design here.)^

= Implementation =
^(Describe and link the implementation results here (from the wiki or the repository).)^

= Testing =
^(Place the testing results here.)^

= Comments =

						desc("deal with remote objects somehow ")

connectors between client and server, modularity relies on the prolib, so the prolib cannot use extensions and extension points.  So the connections should not be attached by extension points but some other mechanism, such as registerConnection API

Resources interface called remoteEntity?  Styles, images,  immutuable objects will be serialized because they are small, remote objects on the other hand are managed with the change server, each has an identifier.