[standards-jig] JEP-0067

Nick nick at jabberstudio.org
Sat Jul 26 01:06:52 UTC 2003


That is fine you have such an in depth view of how equities work and 
are willing to give _constructive_ criticism on the jep. But instead of 
telling someone that it cannot be done or not to waste their time, why 
not help or support him in achieving his goals?

There is no multicasting? I beg to differ. The protocol is merely the 
transport. Ultimately it is up to the layer above the transport layer 
how to move that data. So what do you do? You write a multicaster. NOT 
ROCKET SCIENCE. 
Right now , Peter, you sound like you are astro turfing XMPP as a 
transport layer for some other "professional" software, rather than 
providing strong standards-jig style argument or support for this jep.
-- 

Nicholas Perez
Email: 	nick at jabberstudio.org
Jabber:	nickperez at jabber.org
Home:	303.759.0574

PXR - Perl XML Router - http://pxr.jabberstudio.org


On 2003.07.25 10:44, Peter Ronez wrote:
> 
> --- "Ulrich B. Staudinger" <chicago5 at gmx.de> wrote:
> > Peter,
> >
> > 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 about the exchange that the product is being traded on?
> 
> > 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)
> ---------------------
> 
> > >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
> 



More information about the Standards mailing list