Ulrich B. Staudinger
chicago5 at gmx.de
Fri Jul 25 14:46:26 UTC 2003
Peter Ronez wrote:
>I don't intend to be rude, but I think this JEP has no merit as a Jabber.org
>JEP. Mind you, I think it's a good idea, but the standardization for the
>transmission of equities data (or just common stock in this case) over XMPP is
>beyond the scope of what's currently defined.
>As someone who has worked in a financial firm, writing financial software, I
>can assure you that this is not nearly sufficient for the demands of those
>companies or even day traders. For example, the current JEP has no market depth
>information on a given equities product nor does it even specify the exchange
>that the product is traded on (you need that information to trade). Also, the
>JEP is confined to common stock even though equities options, futures and
>convertables are other essential equity financial products.
Do you mind telling, what is sufficient? Options, futures and common
stock can all be adressed through a specific adress. thanks for pointing
to this, i will add an element <type> to the protocol, a client don't
know if data from a source ISIN DE0005985931 is an option, future or
What do you mean with market depth - money flow index? If you speak of
indicators like momentum, RSI or MFI i have to admit, this has to be
implemented on client side based on historical data. The protocol is
>Now a bit of preemption: You could argue that this the information conveyed by
>this JEP is not tailored for financial institutions, but rather for people who
>have an occasional interest in the markets. If that's the case, then those
>people probably don't need the information in near real-time and probably be
>better served going to Yahoo! for all the graphical, historical data.
>In addition to the shortcomings of the JEP, XMPP is great but it doesn't have
>all the kinds of message delivery reliability / caching that Reuter's Tibco RV
>product line offers. If this is an attempt to make XMPP as an alternative RV
>then you've got your work cut out.
Caching is adressed in the jep through the history query. A user queries
the service to retrieve o/h/l/c+vol data for a specified range in
specified intervals. What do you need more?
Reuters Tibco is a professional solution with professional service and a
fill -time professional support team. Ideas like 'call a support
person'-keys on a keyboard are not adressable with a protocol. Marketing
ideas, like realtime business are not adressed through a jep. Soft
solutions as reuters http://about.reuters.com/productinfo/messaging/
aim to a microsoft target group.
Peter, what key features do you miss? the only thing i can think of are
order informations/order placements and order removals, which i will add
propably in the next version.
Ulrich B. Staudinger
jid: uls at dtedu.net
More information about the Standards