Hi all,
we are interested in your opinion! As one of our main focus is to keep BaseX small and cute (..sad but true: the BaseX core library already exceeds 2mb.. ;), we're currently contemplating the removal of two existing BaseX features, namely..
1) the BaseXHTTP client mode (flag -c). Currently, we offer three operation modes: default, local, and client [1]. In client mode, all requests are supposed to be passed on to yet another BaseX server instance. Currently, however, WebDAV is the only service which is 100% compatible with this mode, while RESTXQ isn't tailored at all to handle remote database requests. Instead, we are contemplating on adding a light-weight XQuery Client API Module, which can then be used to explicitly address remote BaseX instances from within XQuery whenever databases are not stored locally anyway.
2) the current ZIP Module. The functionality won't disappear, though: we will replace it with a new, more flexible proposal specified by Matthias Branter (28msec) and me [2].
In a nutshell: who of you is using either 1) or 2) and would run into big troubles if those features were ousted and replaced with the approaches we believe are more promising for future development?
Thanks as usual for your feedback, either to the list (preferred) or in private, Christian
[1] http://docs.basex.org/wiki/Startup_Options#BaseX_HTTP_Server [2] http://spex.basex.org/index.php?title=ZIP_Module
Christian,
I am using zip module. If you provide same functionality with different approach, that would be fine.
Erol Akarsu
On Thu, May 24, 2012 at 5:03 PM, Christian Grün christian.gruen@gmail.comwrote:
Hi all,
we are interested in your opinion! As one of our main focus is to keep BaseX small and cute (..sad but true: the BaseX core library already exceeds 2mb.. ;), we're currently contemplating the removal of two existing BaseX features, namely..
- the BaseXHTTP client mode (flag -c). Currently, we offer three
operation modes: default, local, and client [1]. In client mode, all requests are supposed to be passed on to yet another BaseX server instance. Currently, however, WebDAV is the only service which is 100% compatible with this mode, while RESTXQ isn't tailored at all to handle remote database requests. Instead, we are contemplating on adding a light-weight XQuery Client API Module, which can then be used to explicitly address remote BaseX instances from within XQuery whenever databases are not stored locally anyway.
- the current ZIP Module. The functionality won't disappear, though:
we will replace it with a new, more flexible proposal specified by Matthias Branter (28msec) and me [2].
In a nutshell: who of you is using either 1) or 2) and would run into big troubles if those features were ousted and replaced with the approaches we believe are more promising for future development?
Thanks as usual for your feedback, either to the list (preferred) or in private, Christian
[1] http://docs.basex.org/wiki/Startup_Options#BaseX_HTTP_Server [2] http://spex.basex.org/index.php?title=ZIP_Module _______________________________________________ BaseX-Talk mailing list BaseX-Talk@mailman.uni-konstanz.de https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
Hello,
I have the feeling my concern about client mode and httpserver did contribute in the raising of question #1. ;-)
Currently we did not implement anything with Httpserver and client mode. The reason I tried this solution (httpserver and distant BaseX DB server) is only for performance. We definitely want to separate the DB mgt server is from the clients just to identify performances bottlenecks and be able to do some tuning. The DB is fed with distant python clients (port 1984). Report clients (HTTP) should also be on a different server.
At the moment, we have a set of xquery scripts that generate HTML pages. They are run on another XMLDB (namely eXist) and want to reuse them on BaseX with a minimal of amount of adaptation.
Hope this helps. Thanks, Gilles.
-----Original Message----- From: basex-talk-bounces@mailman.uni-konstanz.de [mailto:basex-talk- bounces@mailman.uni-konstanz.de] On Behalf Of Christian Grün Sent: jeudi 24 mai 2012 23:04 To: BaseX Subject: [basex-talk] Who is using...?
Hi all,
we are interested in your opinion! As one of our main focus is to keep BaseX small and cute (..sad but true: the BaseX core library already exceeds 2mb.. ;), we're currently contemplating the removal of two existing BaseX features, namely..
- the BaseXHTTP client mode (flag -c). Currently, we offer three operation
modes: default, local, and client [1]. In client mode, all requests are supposed to be passed on to yet another BaseX server instance. Currently, however, WebDAV is the only service which is 100% compatible with this mode, while RESTXQ isn't tailored at all to handle remote database requests. Instead, we are contemplating on adding a light-weight XQuery Client API Module, which can then be used to explicitly address remote BaseX instances from within XQuery whenever databases are not stored locally anyway.
- the current ZIP Module. The functionality won't disappear, though:
we will replace it with a new, more flexible proposal specified by Matthias Branter (28msec) and me [2].
In a nutshell: who of you is using either 1) or 2) and would run into big troubles if those features were ousted and replaced with the approaches we believe are more promising for future development?
Thanks as usual for your feedback, either to the list (preferred) or in private, Christian
[1] http://docs.basex.org/wiki/Startup_Options#BaseX_HTTP_Server [2] http://spex.basex.org/index.php?title=ZIP_Module _______________________________________________ BaseX-Talk mailing list BaseX-Talk@mailman.uni-konstanz.de https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
Hi Gilles,
I have the feeling my concern about client mode and httpserver did contribute in the raising of question #1. ;-)
yes, I remembered your e-mail!
We definitely want to separate the DB mgt server is from the clients just to identify performances bottlenecks and be able to do some tuning.
I'm looking forward to your reaction on the first version of the Client Module [1], available in the latest stable snapshot [2].
Christian
[1] http://docs.basex.org/wiki/Client_Module [2] http://files.basex.org/releases/latest/
Dear all at BaseX,
I can remember a earlier discussion enumerating pros and cons of commands execution within Xquery.
Now that we can execute commands within xquery on a remote server, it would be strange to have to connect to the local server in order to execute commands locally. Are you considering adding this possibility directly in Xquery - for example in the db module, with a db:execute function ?
Are client:execute and client:query updating functions ?
Thank you for your great job on BaseX !
Regards, Fabrice
-----Original Message----- From: Christian Grün [mailto:christian.gruen@gmail.com] Sent: dimanche 27 mai 2012 00:48 To: Gilles CARRY Cc: BaseX Subject: Re: [basex-talk] Who is using...?
Hi Gilles,
I have the feeling my concern about client mode and httpserver did contribute in the raising of question #1. ;-)
yes, I remembered your e-mail!
We definitely want to separate the DB mgt server is from the clients just to identify performances bottlenecks and be able to do some tuning.
I'm looking forward to your reaction on the first version of the Client Module [1], available in the latest stable snapshot [2].
Christian
[1] http://docs.basex.org/wiki/Client_Module [2] http://files.basex.org/releases/latest/
Hi Fabrice,
Now that we can execute commands within xquery on a remote server, it would be strange to have to connect to the local server in order to execute commands locally.
Right; while this is generally possible, it's nothing I would recommended (similar to the use of util:eval()).
Are you considering adding this possibility directly in Xquery - for example in the db module, with a db:execute function ?
It could probably be implemented in less than an hour, but it would cause lots of problems that would cost us much more time.. Instead we'll be gradually complementing the existing db module with the still missing commands.
Which ones – except for db:create() – are you missing most?
Are client:execute and client:query updating functions ?
Nope, as they are tailored to run on a different server. The specified query may be updating, though.
Christian
Hi Christian,
I've made extensive use of the zip module in an application to manipulate EPUB files that do not have XML source.
As long as zip functionality is replaced, I do not foresee any problems rewriting portions of code where necessary.
Cheers,
Dan
On May 24, 2012, at 16:03, Christian Grün christian.gruen@gmail.com wrote:
Hi all,
we are interested in your opinion! As one of our main focus is to keep BaseX small and cute (..sad but true: the BaseX core library already exceeds 2mb.. ;), we're currently contemplating the removal of two existing BaseX features, namely..
- the BaseXHTTP client mode (flag -c). Currently, we offer three
operation modes: default, local, and client [1]. In client mode, all requests are supposed to be passed on to yet another BaseX server instance. Currently, however, WebDAV is the only service which is 100% compatible with this mode, while RESTXQ isn't tailored at all to handle remote database requests. Instead, we are contemplating on adding a light-weight XQuery Client API Module, which can then be used to explicitly address remote BaseX instances from within XQuery whenever databases are not stored locally anyway.
- the current ZIP Module. The functionality won't disappear, though:
we will replace it with a new, more flexible proposal specified by Matthias Branter (28msec) and me [2].
In a nutshell: who of you is using either 1) or 2) and would run into big troubles if those features were ousted and replaced with the approaches we believe are more promising for future development?
Thanks as usual for your feedback, either to the list (preferred) or in private, Christian
[1] http://docs.basex.org/wiki/Startup_Options#BaseX_HTTP_Server [2] http://spex.basex.org/index.php?title=ZIP_Module _______________________________________________ BaseX-Talk mailing list BaseX-Talk@mailman.uni-konstanz.de https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
Christian: We're not using either of these features but I'm more concerned here about the long term stability of the package here. Removing features may be very inconvenient or even create significant issues for existing users. I think ensuring that future versions of the package remains backward compatible is essential for individual and agencies who commit the technology. Of course asking the community is a great way to minimize this issue, but it does not guarantee that a feature we may relying heavily today may end up being voted out down the road. So I'm not sure keeping the package small and cute is that important in comparison to long term stability. I would rather see the package being broken down in multiple .jar files if necessary. Just a though. best *P
On 5/24/12 5:03 PM, Christian Grün wrote:
Hi all,
we are interested in your opinion! As one of our main focus is to keep BaseX small and cute (..sad but true: the BaseX core library already exceeds 2mb.. ;), we're currently contemplating the removal of two existing BaseX features, namely..
- the BaseXHTTP client mode (flag -c). Currently, we offer three
operation modes: default, local, and client [1]. In client mode, all requests are supposed to be passed on to yet another BaseX server instance. Currently, however, WebDAV is the only service which is 100% compatible with this mode, while RESTXQ isn't tailored at all to handle remote database requests. Instead, we are contemplating on adding a light-weight XQuery Client API Module, which can then be used to explicitly address remote BaseX instances from within XQuery whenever databases are not stored locally anyway.
- the current ZIP Module. The functionality won't disappear, though:
we will replace it with a new, more flexible proposal specified by Matthias Branter (28msec) and me [2].
In a nutshell: who of you is using either 1) or 2) and would run into big troubles if those features were ousted and replaced with the approaches we believe are more promising for future development?
Thanks as usual for your feedback, either to the list (preferred) or in private, Christian
[1] http://docs.basex.org/wiki/Startup_Options#BaseX_HTTP_Server [2] http://spex.basex.org/index.php?title=ZIP_Module _______________________________________________ BaseX-Talk mailing list BaseX-Talk@mailman.uni-konstanz.de https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
Dear all,
thanks for your voices! As it seems that the client mode of BaseXHTTP is used by none of you who reacted on my call -- and it's not used in any of the commercial projects we are/have been involved in -- we will most probably remove it in the next official release. Instead, we can already offer a first version of the announced Client Module [1], which you can find in our latest snapshot [2].
Regarding the ZIP proposal, I got 5 reactions; 2 of you said they could easily switch to a new version, and 2 of you asked me to keep the existing proposal alive. As a result, we will probably offer the new proposal (which will first have to be standardized anyway) as an optional alternative, and assign a different prefix to it.
@Pascal: thanks for your sharing your concerns, which I can well understand. There is indeed quite a number of existing features/limitations in BaseX which we would like to revise, but which are still kept alive due to legacy reasons and backward compatibility. Beside that, now and then, we are removing features that (as far as we can find out) are rarely applied in practice. The main reason for that is actually not the file size of the core library, but our limited resources: the more features we provide in parallel, the more time we need to maintain the code base. Some of the feaures on our GitHub issue list have now been listed for nearly one year, which feels frightening... and the removal of obsolete features and a more flexible core (..and some more potential sponsors?) will increase chances that those will be implemented in a foreseeable future.
After all, we'll do our best to take our customer, and all of you participating in the community, as serious as possible; the more feedback we get, the better we'll know how BaseX is used out in the wild.
Cheers, Christian
[1] http://docs.basex.org/wiki/Client_Module [2] http://files.basex.org/releases/latest/
basex-talk@mailman.uni-konstanz.de
-
Christian Grün -
Dan -
Erol Akarsu -
Fabrice Etanchaud -
Gilles CARRY -
Pascal Heus