[standards-jig] JEP-0067

Ulrich B. Staudinger chicago5 at gmx.de
Mon Jul 28 07:32:18 UTC 2003


Peter,

>What about the exchange that the product is being traded on?
>
You mean currency?

>
>  
>
>>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.
>>    
>>
>
>The "current price" in the market is actually not the current price but rather
>the last price that a bid/sell matched and the orders were executed. Now on
>both the bid and sell side there are prices(offers) that haven't matched up.
>For example, I'm selling IBM stock at $40 per share and you have an order for
>buying at $38 per share. The market depth display the buy/sell orders closest
>to the last execution (current) price. It looks something like this:
>
>IBM
>--------------------
>40.00 (5 shares)
>39.90 (4 shares)
>39.20 (20 shares)
>39.00 <-- Last price
>38.90 (5 shares)
>38.80 (8 shares)
>38.00 (1 share)
>---------------------
>  
>
This is what i know as spread - the span from 40 - 38. It doesn't make 
sense to transmit bid/ask, including volume in multiple bid/ask tags - 
traffic volume would increase into very high heights. ;)

Like this:
<data>
<bid>
<val>40</val>
<vol>5</vol>
</bid>
<bid>
<val>39.9</val>
<vol>4</vol>
</bid>
...
<ask>
<val>38</val>
<vol>1</vol>
</bid>

</data>

It makes more sense to add something i noted in the before-last mail, 
order placement and removal - not for real trading  (ordering/selling) 
but for expressing the fact that someone else places an order.

i think it should work similar to xmpp's presence or jabber:iq:roster 
push upon presence subscription.

<data>
<bid action='add'>
<val>40</val>
<vol>5</vol>
</bid>
<bid action='add'>
<val>39.9</val>
<vol>4</vol>
</bid>
</data>

this sort of pushes make sense to me. now, if a trade has been made, 
bids/asks for the trade have to be removed:

<data>
<bid action='rem'>
<val>39.1</val>
<vol>10</vol>
</bid>
<bid action='rem'>
<val>39</val>
<vol>50</vol>
</bid>
<ask action='rem'>
<val>38.9</val>
<vol>40</vol>
</bid>
<ask action='rem'>
<val>38.5</val>
<vol>10</vol>
</bid>
</data>


?

regards,
ulrich




>  
>
>>>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.
>>    
>>
>
>That's not the argument. Forget their instant messaging solution and their
>support -- let's talk about RV. RV uses multicast, XMPP does not. That's it,
>end of story. Without multicast, the XMPP solution won't nearly scale as well. 
>
>This doesn't mean that XMPP isn't well suited for financial companies -- it is!
>However, multicasting large amounts of data is not one of those things.
>
>  
>
>>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.
>>    
>>
>
>Wow! Now you've unleashed a whole new can of worms! Order execution is ten fold
>more involved in comparison to publishing of market information. I strongly
>advise you not to waste your time.
>
>Anyway, from what I can tell from your answers, you obviously have some grand
>ambitions for your client in the financial world, and that's fine. But,
>irregardless of the JEP's short comings, XMPP is not suited for broadcasting
>financial data.
>
>__________________________________
>Do you Yahoo!?
>The New Yahoo! Search - Faster. Easier. Bingo.
>http://search.yahoo.com
>_______________________________________________
>Standards-JIG mailing list
>Standards-JIG at jabber.org
>http://mailman.jabber.org/listinfo/standards-jig
>
>
>  
>


-- 
Ulrich B. Staudinger
http://www.die-horde.de
jid: uls at dtedu.net





More information about the Standards mailing list