[standards-jig] JEP-0067

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 
common stock.

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 
very generic.

>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 mailing list