Hi Group,
Thanks for the effort put in to this project.
I have a several questions you might be able to shed some light on:
1) org.otfeed web site indicates: 'However, API calls are not compatible with the ones provided by Opentick Corporation. Therefore, org.otfeed can not be used as a drop-in replacement of the Opentick Driver'
Could some one outline what the reasons were for this divergence?
2) My impression is that opentick.com is more 'closed' than org.otfeed, e.g no dev mail list, Although http://code.google.com/p/otfeed-patches seems active its difficult to workout how much collaboration there is outside of opentick.com.... can any one confirm these impressions or have any insights? Is there any membership of overlap between the two groups?
3) As far as I can tel there is no xsd/xml description of the OT message specification, correct? Has such a thing been contemplated (for generating client OT code), or is there too much behavior to implement - leaving only constants and methods stubs to be extracted from any xml?
4) What does org.otfeed track; opentick.com's web description, OT.com server behavior (presumably reverse engineered?), OT.com cvs or otfeed-patches?
Mark
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
1: org.otfeed api is different because the other one seem too ugly (reads: no reason :). It is relatively easy to write an adapter to make org.otfeed expose their "standard" api. However, there seem to be no interest for that. I suspect that there are no production applications that use opentick.com java adapter as they admit the lack of support for it.
2: there is no collaboration, currently.
3: my feeling is that its easier to do coding in java than in xml. Besides, there is no one-to-one correspondence between on-wire message and resulting one (i.e. sometimes compressed message is sent over-the-wire, resulting in a bunch of messages produced by api).
4: org.otfeed takes into consideration everything. In case of protocol differences, .NET driver is used as the reference one.
-Mike
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Group,
Thanks for the effort put in to this project.
I have a several questions you might be able to shed some light on:
1) org.otfeed web site indicates: 'However, API calls are not compatible with the ones provided by Opentick Corporation. Therefore, org.otfeed can not be used as a drop-in replacement of the Opentick Driver'
Could some one outline what the reasons were for this divergence?
2) My impression is that opentick.com is more 'closed' than org.otfeed, e.g no dev mail list, Although http://code.google.com/p/otfeed-patches seems active its difficult to workout how much collaboration there is outside of opentick.com.... can any one confirm these impressions or have any insights? Is there any membership of overlap between the two groups?
3) As far as I can tel there is no xsd/xml description of the OT message specification, correct? Has such a thing been contemplated (for generating client OT code), or is there too much behavior to implement - leaving only constants and methods stubs to be extracted from any xml?
4) What does org.otfeed track; opentick.com's web description, OT.com server behavior (presumably reverse engineered?), OT.com cvs or otfeed-patches?
Mark
Hi Mark,
Answers:
1: org.otfeed api is different because the other one seem too ugly (reads: no reason :). It is relatively easy to write an adapter to make org.otfeed expose their "standard" api. However, there seem to be no interest for that. I suspect that there are no production applications that use opentick.com java adapter as they admit the lack of support for it.
2: there is no collaboration, currently.
3: my feeling is that its easier to do coding in java than in xml. Besides, there is no one-to-one correspondence between on-wire message and resulting one (i.e. sometimes compressed message is sent over-the-wire, resulting in a bunch of messages produced by api).
4: org.otfeed takes into consideration everything. In case of protocol differences, .NET driver is used as the reference one.
-Mike