Re: [Geotools-devel] GeoServer binary communication question

[<gab...@te...>]

> >
> > 3) Binary Communication. Now we are using a propiety protocol. But wed
> > love to a b-xml implementation... Are someone planning to release a
> > B-XML implementation? Is anyone interested in discuss this?

I am (both interested and planning). I was actually giving a change to
CubeWerx to release it's anounced open source, high performance, versatil
and JAXP compliant BXML implementation. Don't ask me where exactly I'd read
it, but will check again and think in implement it more seriously; so if you
or someone else is interested in combining efforts it will be great.

> >
> > 4) Bidirectional communications based in full-duplex sockets. Think in
> > a client making a zoom of all the world. It renders world's countrys
> > while it reads country's features from our server. If we don allow
> > client to finish zoom (making another zoom to canada, for example)
> > with a full duplex socket we neednt to close connection and open
> > another one. Instead, we read data from server by buckets (like fetch
> > size of Oracle), and when we complete a bucket, server waits for a
> > control byte. We send a cancel byte and server stops sending worlds
> > countrys to client, and start wait for another request.
>
I think this is the way a geotools' datastore could work. And from a desktop
client view point, I would love to see one that
can work both against a gt2 datastore (say oracle, postgis, shapefile,
arcsde, etc) and a WFS ((through gml, gml+b-xml, ...), (a WFSDataStore?)).
But for WMS and WFS, the spec says explicitly that the only DCP (distributed
computing platform) targeted by the moment is HTTP 1.1,
so I think we're a bit tied to this by now.

From a corporate perspective, a good reasson to use a WFS datasore instead
Status: O

of, say, an ArcSDEDataStore directly for a desktop client, shoud be license
economy, so a lot of clients can be working in parallel without consuming so
many licenses (actually we own 74 ArcSDE licenses and it's still not enough,
while a single connection inside geoserver can support up to 24 concurrent
requests - empirically tested-)

Again, I don't really think an HTTP approach should be so significant,
taking in count that with a full duplex approach one will be only avoiding
the per request http connection time, but still have the request (filter)
parsing, encoding, executing and reading times. With the SPEED stratagy
configured in geoserver, just closing the socket will abort the processing,
wich is cool enough compared to the other posibility of waiting for getting
a full result before sending content to the client.
Anyway, it's clear that I didn't done any experiment about the performance
impact suppossed by this, so it's just a thinking.

In resume, if I want high performance in a client connection over a backend,
I may be use a specific datastore. If I want flexibility and
interoperability, I should use a WFS. The ideal should be a client wich
supports both.

best regards,

Gabriel