Re: [basex-talk] Web sockets and BaseX

[Christian Grün]

Hi Marco, hi France,

Thanks for the feedback on creating web sockets. Feel free to tell us
how the BaseX code could be modified to get it embedded more smoothly.

Best,
Christian


On Mon, Oct 31, 2016 at 3:46 PM, Marco Lettere  wrote:
> Hi France,
> I can confirm that for using websocket you'll have to write some Java code.
> That's what we've done for creating a Jetty Connector that is able to accept
> websocket connections from HTML5 apps running inside browsers.
> Then we interact from inside XQuery by using the mechanism of Java Bindings
> [1] when we have to send out messages.
>
> We used Jetty package that comes with Basex just adding [2] to the lib
> folder.
> The only caveat we stumbled upon is, hope I'm recalling the right story
> here, that it's not possible to just add a new Connector to the jetty.xml
> file because BaseX ignores every connector but the first one [3] (I ask
> Christian to possibly confirm or confute this). Thus we needed to configure
> the Jetty connector from inside the Java code which is not optimal for us
> but works.
>
> Hope this helps.
> Ciao,
> Marco.
>
> [1] http://docs.basex.org/wiki/Java_Bindings
> [2] jetty-websocket-8.1.18.v20150929.jar
> [3]
> https://github.com/dcore94/basex/blob/master/basex-api/src/main/java/org/basex/BaseXHTTP.java#L100
>
>
> On 31/10/2016 10:19, France Baril wrote:
>
> Has anyone implemented a solutions that uses web sockets with BaseX? I've
> been doing some work with socket.io and node.js, but all the research I've
> done on Jetty points to the need to create .java files that manage the
> connection on the server side. Does that mean I'd need a BaseX module to
> manage that? Since Jetty seems to support web sockets, do you forsee any
> other issues specific to BaseX?
>
>
> --
> France Baril
> Architecte documentaire / Documentation architect
> france.ba...@architextus.com
>
>

Re: [basex-talk] Web sockets and BaseX

[Marco Lettere]

Hi France,
I can confirm that for using websocket you'll have to write some Java 
code. That's what we've done for creating a Jetty Connector that is able 
to accept websocket connections from HTML5 apps running inside browsers.
Then we interact from inside XQuery by using the mechanism of Java 
Bindings [1] when we have to send out messages.


We used Jetty package that comes with Basex just adding [2] to the lib 
folder.
The only caveat we stumbled upon is, hope I'm recalling the right story 
here, that it's not possible to just add a new Connector to the 
jetty.xml file because BaseX ignores every connector but the first one 
[3] (I ask Christian to possibly confirm or confute this). Thus we 
needed to configure the Jetty connector from inside the Java code which 
is not optimal for us but works.


Hope this helps.
Ciao,
Marco.

[1] http://docs.basex.org/wiki/Java_Bindings
[2] jetty-websocket-8.1.18.v20150929.jar
[3] 
https://github.com/dcore94/basex/blob/master/basex-api/src/main/java/org/basex/BaseXHTTP.java#L100


On 31/10/2016 10:19, France Baril wrote:
Has anyone implemented a solutions that uses web sockets with BaseX? 
I've been doing some work with socket.io  and 
node.js, but all the research I've done on Jetty points to the need to 
create .java files that manage the connection on the server side. Does 
that mean I'd need a BaseX module to manage that? Since Jetty seems to 
support web sockets, do you forsee any other issues specific to BaseX?



--
France Baril
Architecte documentaire / Documentation architect
france.ba...@architextus.com 

Re: [basex-talk] map:merge new semantics for 8.6

[Marc van Grootel]

Thanks Christian,
I feared as much ;-(
I understand the reasoning (processing efficiency and compatibility
with parse-json) but find it unfortunate that backwards compatibility
wasn't part of the reasoning as maps and map:merge are not exactly
new.

--Marc

On Mon, Oct 31, 2016 at 1:50 PM, Christian Grün
 wrote:
> Hi Marc,
>
> The reason is why this was decided by the W3C; see [1] and related comments.
>
> Sorry for that,
> Christian
>
> [1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=29723
>
>
>
> On Mon, Oct 31, 2016 at 1:43 PM, Marc van Grootel
>  wrote:
>> Hi,
>>
>> Any reason why the deault semantics for map:merge in 8.6 changed in a
>> backwards incompatible manner? Is this because of some XQuery/XPath
>> spec thing? A while ago I switched to 8.6-SNAPSHOT just to be on the
>> latest and greatest and I starting seeing weird things in my code.
>> Initially I didn't bother to look at the docs as I didn't expect
>> map:merge to have changed. At some point I even thought map:merge was
>> broken in this snapshot. I often use map:merge for handling function
>> options and I add the defaults first and then user options. With 8.6
>> this default behaviour has changed and I would have to switch this
>> around or explicitly ask for 'use-last'. I can do but only by adding
>> map { 'duplicates': 'use-last' }. This means I will have code <= 8.5
>> and I need to have different code for > 8.5.
>> Was this intentional? If not then I would vote for re-instating
>> default behaviour (use-last).
>>
>> Cheers,
>> --Marc



-- 
--Marc

Re: [basex-talk] map:merge new semantics for 8.6

[Christian Grün]

Hi Marc,

The reason is why this was decided by the W3C; see [1] and related comments.

Sorry for that,
Christian

[1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=29723



On Mon, Oct 31, 2016 at 1:43 PM, Marc van Grootel
 wrote:
> Hi,
>
> Any reason why the deault semantics for map:merge in 8.6 changed in a
> backwards incompatible manner? Is this because of some XQuery/XPath
> spec thing? A while ago I switched to 8.6-SNAPSHOT just to be on the
> latest and greatest and I starting seeing weird things in my code.
> Initially I didn't bother to look at the docs as I didn't expect
> map:merge to have changed. At some point I even thought map:merge was
> broken in this snapshot. I often use map:merge for handling function
> options and I add the defaults first and then user options. With 8.6
> this default behaviour has changed and I would have to switch this
> around or explicitly ask for 'use-last'. I can do but only by adding
> map { 'duplicates': 'use-last' }. This means I will have code <= 8.5
> and I need to have different code for > 8.5.
> Was this intentional? If not then I would vote for re-instating
> default behaviour (use-last).
>
> Cheers,
> --Marc

[basex-talk] map:merge new semantics for 8.6

[Marc van Grootel]

Hi,

Any reason why the deault semantics for map:merge in 8.6 changed in a
backwards incompatible manner? Is this because of some XQuery/XPath
spec thing? A while ago I switched to 8.6-SNAPSHOT just to be on the
latest and greatest and I starting seeing weird things in my code.
Initially I didn't bother to look at the docs as I didn't expect
map:merge to have changed. At some point I even thought map:merge was
broken in this snapshot. I often use map:merge for handling function
options and I add the defaults first and then user options. With 8.6
this default behaviour has changed and I would have to switch this
around or explicitly ask for 'use-last'. I can do but only by adding
map { 'duplicates': 'use-last' }. This means I will have code <= 8.5
and I need to have different code for > 8.5.
Was this intentional? If not then I would vote for re-instating
default behaviour (use-last).

Cheers,
--Marc

[basex-talk] Web sockets and BaseX

[France Baril]

Has anyone implemented a solutions that uses web sockets with BaseX? I've
been doing some work with socket.io and node.js, but all the research I've
done on Jetty points to the need to create .java files that manage the
connection on the server side. Does that mean I'd need a BaseX module to
manage that? Since Jetty seems to support web sockets, do you forsee any
other issues specific to BaseX?


-- 
France Baril
Architecte documentaire / Documentation architect
france.ba...@architextus.com