For me helps by having the schema that allows for something some other service uses to do the automatic merging using the tools available in dosgi, but I understand that nothing can be really automatic because it can require merges and there is garbage collection that will need to happen on the objects during reconciliation. If the DTO's are just public fields they do not offer anything over using a pojo. Where they start to be useful to me is by defining in a standard way how the data can be turned into an object. Examples would be a way to define a key so that indexes and equality can be determined, or defining relationships between sub objects so when doing a deep clone the user can decide how many links to traverse. Scoping rules could also be defined so the converter has information that could be used in determining which type of object to serialize to in different situations. The standard can choose not to define these things and let the application decide in order to be more flexible or it can try to define some of these things in order to make services or tools around DTO's more standardized. I think I am trying to follow what schema elements will be in DTO's and make sure that I take advantage of them rather than writing my own. As of right now that I am just using them as pojo's though so I don't have any feelings or advice on the way to go and what types of schema things I would be able to take advantage of.
On Thu, Aug 18, 2016 at 4:23 AM, David Bosschaert < [email protected]> wrote: > Hi Davids, > > What is it exactly from that article that you think would make sense in the > context of OSGi? The automatic merging of concurrent data updates? > > Thanks, > > David > > On 18 August 2016 at 07:50, David Leangen <[email protected]> wrote: > > > > > That is interesting, indeed! I only quickly skimmed through the article, > > but it does indeed appear to be a potentially interesting property for > > dosgi. > > > > If I believe what the authors write in the abstract, it provides a > > relatively simple and deterministic method that could be implemented in > > code. > > > > Cheers, > > =David > > > > > > > On Aug 17, 2016, at 10:21 PM, David Daniel < > [email protected]> > > wrote: > > > > > > read an interesting article this morning http://arxiv.org/abs/1608. > 03960 > > > Something like this would be an interesting property to have for dosgi > > > which is one of the use cases for DTO's > > > > > > On Wed, Aug 17, 2016 at 6:47 AM, David Leangen (JIRA) <[email protected] > > > > > wrote: > > > > > >> > > >> [ https://issues.apache.org/jira/browse/FELIX-5325?page= > > >> com.atlassian.jira.plugin.system.issuetabpanels:comment- > > >> tabpanel&focusedCommentId=15424288#comment-15424288 ] > > >> > > >> David Leangen commented on FELIX-5325: > > >> -------------------------------------- > > >> > > >> Awesome. Thank you! :-) > > >> > > >>> Patch for embedded DTO (in DTO) > > >>> ------------------------------- > > >>> > > >>> Key: FELIX-5325 > > >>> URL: https://issues.apache.org/jira/browse/FELIX-5325 > > >>> Project: Felix > > >>> Issue Type: Improvement > > >>> Components: Converter > > >>> Reporter: David Leangen > > >>> Assignee: David Bosschaert > > >>> Priority: Minor > > >>> Attachments: patch.diff > > >>> > > >>> > > >>> This patch adds support for converting a DTO that contains an > embedded > > >> DTO. It uses recursive calls to Converter.convert() to accomplish > this. > > >> > > >> > > >> > > >> -- > > >> This message was sent by Atlassian JIRA > > >> (v6.3.4#6332) > > >> > > > > >
