Remove XQueryServlet

[adamretter]

For quite some time XQueryServlet has been deprecated and we have recommended that people instead store their XQuery in the database. The eXist book also makes the same recomendation.
I would like to remove this old for a long time deprecated code.

[dizzzz]

Isn't the controller using this servlet? or betterForm? It would cause regression for some people, but for a v3.0 release -when correctly documented and announced- acceptible IMO.

[shabanovd]

It used for in db xquery scripts too. Maybe, it can be split by usecases: db, FS and code as request parameter. I'd like to remove last one, but there people that use it, so removing may/will break there apps.

[wolfgangmm]

It is still being used quite a lot as I know from customers, e.g. in applications which embed eXist. In some scenarios it makes sense to keep queries on the file system.

eXide also uses it to post XQuery code if you press the "Eval" button (same for the demo app). Changing all this would imply a lot of work, taking time from other things.

[adamretter]

@shabanovd Sorry can you tell me why it would be used in DB XQuery Scripts? I thought that was what RESTServer was for?

@wolfgangmm Can you explain why eXide uses this rather than posting the XQuery via RESTServer?

[dizzzz]

@adamretter please read wolf's answer a bit slower ; there is no real reason as I read it but since there are dependencies with for example eXide, and timing constraints, it cannot be removed.

[adamretter]

@dizzzz I read the answer. I just wanted more information. Surely I could do the changes on eXide if I wished to - I think it is still Open Source right?

[dizzzz]

:-) yes :-)

[wolfgangmm]

Ignore eXide. We can change that ourselves if we like to.

The relevant info is that some of the biggest users of eXist I know of still rely on XQueryServlet in an embedded context.

[adamretter]

@wolfgangmm Is the goal to continue to advise against the XQueryServlet. Is so what is the timescale for removing it?

[JoernT]

I think it was not wrong what we did with the SOAP API - we can simply ask people if they still rely on it (and why) and probably (optionally) make clear that the XQueryServlet is deprecated and give some advise what to use instead. If there are still users of it we can probably set some relaxed deadline before removal.

However if there's still a valid use case for it - XQueries being stored on the filesystem or similar - then we should probably rethink the deprecation.

[wolfgangmm]

@adamretter I always advise against the XQueryServlet and communicate this to our customers. Some of them are currently struggling hard (involving large teams) to finally migrate to eXist 2.x and I certainly don't want to make it even harder for them by raising the bar too high. Switching from a file system based architecture to one in the database is not always straightforward. We definitely have to give those guys more time to adopt (end of the year I'd say).

[ljo]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Den 2015-04-02 14:01, Wolfgang Meier skrev:

definitely have to give those guys more time to adopt (end of the
year I'd say).

Yes, I suggest we decide to communicate a date in the coming release.
So the next next (the one after the coming) release would be an
obvious target I say.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iD8DBQFVHTE9hcIn5aVXOPIRAvqtAJ9Gy09j/Gjjv7sI/5FC2iQ6Q9vfawCgkYUA
7OHII33d4Uwgu062QGl7QpE=
=XTQv
-----END PGP SIGNATURE-----