From: Evgeny G. <gaz...@gm...> - 2010-05-27 15:27:06
|
Hello! I want to release the function system:register-module($qname, $path) for registering modules at runtime without restarting eXist. Your suggestions? -- Evgeny |
From: Dannes W. <da...@ex...> - 2010-05-27 15:50:27
|
Hi, On Thu, May 27, 2010 at 5:26 PM, Evgeny Gazdovsky <gaz...@gm...> wrote: > I want to release the function system:register-module($qname, $path) > for registering modules at runtime without restarting eXist. > Your suggestions? Well it is just a part of the whole story. If you want to be able to register it this way then..... you must also be able to unregister it as well. And that might be exciting to do...... cheers Dannes -- eXist-db Native XML Database - http://exist-db.org Join us on linked-in: http://www.linkedin.com/groups?gid=35624 |
From: Evgeny G. <gaz...@gm...> - 2010-05-27 16:06:33
|
like for unregestiring need access to every query context... |
From: Thomas W. <tho...@gm...> - 2010-05-27 16:15:09
|
> like for unregestiring need access to every query context... And may be enumerating all modules imported in a .xql and .xqm file. Thomas |
From: Dmitriy S. <sha...@gm...> - 2010-05-27 16:52:46
Attachments:
smime.p7s
|
On Thu, 2010-05-27 at 20:06 +0400, Evgeny Gazdovsky wrote: > like for unregestiring need access to every query context... It should be simple, all you need is to change configuration@util. Well, we a talking about two different things: 1. dynamically import; 2. preregistered modules (like util or xmldb) are you talking about dynamic import? -- Cheers, Dmitriy Shabanov |
From: Evgeny G. <gaz...@gm...> - 2010-05-27 18:25:45
|
> It should be simple, all you need is to change configuration@util. Well, > we a talking about two different things: 1. dynamically import; 2. > preregistered modules (like util or xmldb) > > are you talking about dynamic import? > Not I'm about dynamic registering, so we can use our modules like eXist's whitout "at" clause and can also store them and move in/out db. Also this is usefull for autogenerated modules and queries. -- Evgeny |
From: Joe W. <jo...@gm...> - 2010-05-27 18:52:28
|
Hi Evgeny, > I want to release the function system:register-module($qname, $path) > for registering modules at runtime without restarting eXist. I would really find this useful. One more question: How long would the modules persist as registered? Only until the database was shut down, or even after it's restarted? Joe |
From: Evgeny G. <gaz...@gm...> - 2010-05-27 19:01:08
|
2010/5/27 Joe Wicentowski <jo...@gm...>: > Hi Evgeny, > >> I want to release the function system:register-module($qname, $path) >> for registering modules at runtime without restarting eXist. > > I would really find this useful. One more question: How long would > the modules persist as registered? Only until the database was shut > down, or even after it's restarted? > yes, until restarted. But you always register your modules at startup via scheduler and you own script. -- Evgeny > Joe > |
From: José M. F. G. <jm...@us...> - 2010-05-27 19:22:48
|
Hi everybody, this will also needed for module reloading, very useful when you are upgrading or developing. For instance, much of the XQM modules used by Atomic Wiki live in a jar file, which is loaded from conf.xml. If you need to update some module, you have to restart the database engine if you cannot dynamically unload/load it. José María -- "La violencia es el último recurso del incompetente" - Salvor Hardin en "La Fundación" de Isaac Asimov "Premature optimization is the root of all evil." - Donald Knuth José María Fernández González e-mail: jos...@gm... |
From: Evgeny G. <gaz...@gm...> - 2010-05-28 08:24:14
|
2010/5/27 José María Fernández González <jm...@us...>: > Hi everybody, > this will also needed for module reloading, very useful when you are > upgrading or developing. For instance, much of the XQM modules used by > Atomic Wiki live in a jar file, which is loaded from conf.xml. If you need > to update some module, you have to restart the database engine if you cannot > dynamically unload/load it. > This is another case. In this case you are need dynamic jar loading -- Evgeny |
From: Dannes W. <da...@ex...> - 2010-05-30 09:05:32
|
Hi Evgeny , thnx for your contribution, but I am not sure yet if we really want to have it... this way I am concerned about the "map-module", there is a security risk now. This function should only be used by a admin/dba user. Please add this security check and please add a set of unit tests for this new function. (see developers manifesto) regards Dannes 2010/5/28 Evgeny Gazdovsky <gaz...@gm...>: > 2010/5/27 José María Fernández González <jm...@us...>: >> Hi everybody, >> this will also needed for module reloading, very useful when you are >> upgrading or developing. For instance, much of the XQM modules used by >> Atomic Wiki live in a jar file, which is loaded from conf.xml. If you need >> to update some module, you have to restart the database engine if you cannot >> dynamically unload/load it. >> > This is another case. In this case you are need dynamic jar loading > > -- > Evgeny > -- eXist-db Native XML Database - http://exist-db.org Join us on linked-in: http://www.linkedin.com/groups?gid=35624 |
From: Evgeny G. <gaz...@gm...> - 2010-05-30 11:01:06
|
> thnx for your contribution, but I am not sure yet if we really want to > have it... this way > > I am concerned about the "map-module", there is a security risk now. > This function should only be used by a admin/dba user. Please add this > security check and please add a set of unit tests for this new > function. (see developers manifesto) > > regards > Dannes > > add DBA access only? -- Evgeny |
From: Evgeny G. <gaz...@gm...> - 2010-05-30 11:33:16
|
2010/5/30 Dannes Wessels <da...@ex...>: > Hi Evgeny , > > thnx for your contribution, but I am not sure yet if we really want to > have it... this way 2010/5/27 Thomas White <tho...@gm...>: > If I have a file A the imports module B, that imports module C at the > moment all imports are resolved to the main file A. > > If we want to make a libraries made of multiple files then imports > should be able to be relative to the current importing file - in this > case the path for importing module C should be relative to module B. > > In order to keep existing functionality we can use 'at-relative' > instead of 'at' when we import a module in a relative fashion. > Back in Prague Dmitriy said it should be relatively simple to > implement this functionality. > Now you can move your xquery source without changing the "at" clause in them. Becouse you can use modules whithout one. You can map madules dinamicaly, for example, by trigger and XQdoc function to get namespace of your module. Also you can use different versions of your modules for debugging or other purpose. Simple remap one dinamicaly. -- Evgeny Evgeny |
From: Thomas W. <tho...@gm...> - 2010-05-30 13:25:54
|
Evgeny, I think you are missing my point. It is not question of dynamic or static import it is about the import context. If we have a library that consists of 50 .xql modules and there are 5 main modules that combine a subset of these modules for a specific functionality imported into the XQueries what generate the user interface. There are many reasons why we will prefer to use the main 5 import files instead of the mini module files: 1) The library vendor may decide to change some of the implementations and reshuffle of some some of the function from one module to another. When we import a main module file that imports what is necessary we do not need to know which modules are used and what are their names, locations and name spaces. 2) We may want to reduce the memory footprint in a busy site because for every module loaded an instance of the module is created into the memory. At the moment we can not have libraries of XQuery modules files because the module import context is always the main XQuery file. If the a module 'A' imports some other modules the paths in 'at' clause would be updated to reflect the relative path to the main modules. This is not practical (if the module file is imported from more then one main XQuery, and some times it is not possible - if a module is in a JAR file we can not update the import paths. The only possible way to deal with this serious limitation is to put all XQuery and module files in the same directory. It is a number game after all. If we do small applications then we can have all files in a single directory. If we have a bigger project it is obvious to use directories to separate sections of the project for every team and have all modules into a single directory. But it is so inconvenient when the functionality is shared - then instead of giving a single import file to be used by other teams, we have to give a list of all our modules to be included one by one. The obvious solution - have own copy of the modules in every project is a single directory. :-( Can you imagine if we have to produce a content with XSLT and if we have had the same import context limitation and all imported XSLT should always have an URI relative to the main XSLT. I do not know about you but I can't. What I am have been advocating for quite some time is to introduce a variation of the 'at' clause in the import command *'at-relative'* that will resolve all import files path relative to the file that does the importing. Then we can create libraries of XQuery modules and share functionality much easily and we can group our XQuery code in directories anyway we like. I really hope some of the leading developers will be able to spend some time and add *'at-relative'* to the import command. Regards, Thomas ------ Thomas White Mobile:+44 7711 922 966 Skype: thomaswhite gTalk: thomas.0007 Linked-In:http://www.linkedin.com/in/thomaswhite0007 facebook: http://www.facebook.com/thomas.0007 On 30 May 2010 12:33, Evgeny Gazdovsky <gaz...@gm...> wrote: > 2010/5/30 Dannes Wessels <da...@ex...>: >> Hi Evgeny , >> >> thnx for your contribution, but I am not sure yet if we really want to >> have it... this way > > 2010/5/27 Thomas White <tho...@gm...>: >> If I have a file A the imports module B, that imports module C at the >> moment all imports are resolved to the main file A. >> >> If we want to make a libraries made of multiple files then imports >> should be able to be relative to the current importing file - in this >> case the path for importing module C should be relative to module B. >> >> In order to keep existing functionality we can use 'at-relative' >> instead of 'at' when we import a module in a relative fashion. >> Back in Prague Dmitriy said it should be relatively simple to >> implement this functionality. >> > > Now you can move your xquery source without changing the "at" clause > in them. Becouse you can use modules whithout one. > You can map madules dinamicaly, for example, by trigger and XQdoc > function to get namespace of your module. > > Also you can use different versions of your modules for debugging or other > purpose. Simple remap one dinamicaly. > > -- > Evgeny > Evgeny > > ------------------------------------------------------------------------------ > > _______________________________________________ > Exist-development mailing list > Exi...@li... > https://lists.sourceforge.net/lists/listinfo/exist-development > |
From: Evgeny G. <gaz...@gm...> - 2010-05-30 13:46:26
|
Hi, Thomas! I'm understand you and I'd same problem too, one of example is using stored modules via XMLRPC. I'm say that now you can solve the like problem, becouse, now, location of modules is not importinant. Yes, this is not crossplatform. and this is one of solutions. So you can write your libreries whithout "at" clause (if you use mapping). This is extension of mapping of modules in conf.xml. So, for example, I'd pursue another purpose. I'd autogenerate xquery modules from different XML declarations and store them in some temporory collections. I want import this modules, but I wan't know where them stored! And this solution is do it. This is not the replacement of "at-relative". -- Evgeny |
From: Thomas W. <tho...@gm...> - 2010-05-30 21:54:49
|
Evgeny, I like the functionality you are working on and I can see its potential for using it with single file self-contained modules. I am sure when your extension is available we are going to find a lot of ways to make our code more flexible, more dynamic and less dependent of config files. Something that is missing in our eXist community is a repository of reusable library files where we can share what we have done and help each other not to reinvent the hot watter again and again. I bet almost everyone of us after a couple of months work with eXist has something useful to share with others. We miss a huge opportunity to have an exponential growth of shared knowledge and expertise. I am a strong believer that 'at-relative' extension of the import clause will change the situation dramatically in our favour. When it is easier to share and reuse other developer's work then the community will pick up this opportunity quickly and in short period of time we can accumulate a significant repository of reusable eXist modules, both XQuery and JAVA based. I hope I have convinced most of you about the importance of having 'at-relative' extension of the import clause. Thomas ------ Thomas White Mobile:+44 7711 922 966 Skype: thomaswhite gTalk: thomas.0007 Linked-In:http://www.linkedin.com/in/thomaswhite0007 facebook: http://www.facebook.com/thomas.0007 On 30 May 2010 14:46, Evgeny Gazdovsky <gaz...@gm...> wrote: > Hi, Thomas! > > I'm understand you and I'd same problem too, one of example is using > stored modules via XMLRPC. > I'm say that now you can solve the like problem, becouse, now, > location of modules is not importinant. > Yes, this is not crossplatform. and this is one of solutions. So you > can write your libreries whithout "at" > clause (if you use mapping). > This is extension of mapping of modules in conf.xml. > So, for example, I'd pursue another purpose. I'd autogenerate xquery > modules from different > XML declarations and store them in some temporory collections. I want > import this modules, > but I wan't know where them stored! And this solution is do it. > > This is not the replacement of "at-relative". > > -- > Evgeny > |
From: Dannes W. <da...@ex...> - 2010-05-31 14:30:45
|
Hi, On Sun, May 30, 2010 at 11:54 PM, Thomas White <tho...@gm...> wrote: > Something that is missing in our eXist community is a repository of reusable > library files where we can share what we have done and help each other not > to reinvent the hot watter again and again. I bet almost everyone of us > after a couple of months work with eXist has something useful to share with > others. We miss a huge opportunity to have an exponential growth of shared > knowledge and expertise. Well we could host these xqm's on http://code.google.com/p/existdb-contrib/ ..... regards Dannes -- eXist-db Native XML Database - http://exist-db.org Join us on linked-in: http://www.linkedin.com/groups?gid=35624 |
From: Joe W. <jo...@gm...> - 2010-05-31 00:01:00
|
Evgeny - Cool. I am looking forward to giving these new functions a try. I think Dannes asked for unit tests too - something I think is necessary to ensure the functions can stay in trunk. Could you contribute unit tests when you have the chance? Also is there a deregister/unmap function, or only a register function? Thomas - I am definitely in favor of features that enable sharing. But I'm sorry, I'm having trouble understanding what you mean by "at-relative"; I'm not dubious, I just don't get it yet. Could you illustrate with a simple, concrete scenario? A few requests: Could you define your terms a bit? (.xql is ambiguous. Library module vs. main module is a distinction we agree on; namely, http://www.w3.org/TR/xquery/#dt-main-module vs. http://www.w3.org/TR/xquery/#dt-library-module.) Also, should this go in a separate thread? Thanks, Joe On Sun, May 30, 2010 at 5:54 PM, Thomas White <tho...@gm...> wrote: > Evgeny, > > I like the functionality you are working on and I can see its potential > for using it with single file self-contained modules. I am sure when your > extension is available we are going to find a lot of ways to make our code > more flexible, more dynamic and less dependent of config files. > > Something that is missing in our eXist community is a repository of reusable > library files where we can share what we have done and help each other not > to reinvent the hot watter again and again. I bet almost everyone of us > after a couple of months work with eXist has something useful to share with > others. We miss a huge opportunity to have an exponential growth of shared > knowledge and expertise. > > I am a strong believer that 'at-relative' extension of the import clause > will change the situation dramatically in our favour. When it is easier to > share and reuse other developer's work then the community will pick up this > opportunity quickly and in short period of time we can accumulate a > significant repository of reusable eXist modules, both XQuery and JAVA > based. > > I hope I have convinced most of you about the importance of having > 'at-relative' extension of the import clause. > > Thomas > > > > > > ------ > > Thomas White > > Mobile:+44 7711 922 966 > Skype: thomaswhite > gTalk: thomas.0007 > Linked-In:http://www.linkedin.com/in/thomaswhite0007 > facebook: http://www.facebook.com/thomas.0007 > > > > On 30 May 2010 14:46, Evgeny Gazdovsky <gaz...@gm...> wrote: >> >> Hi, Thomas! >> >> I'm understand you and I'd same problem too, one of example is using >> stored modules via XMLRPC. >> I'm say that now you can solve the like problem, becouse, now, >> location of modules is not importinant. >> Yes, this is not crossplatform. and this is one of solutions. So you >> can write your libreries whithout "at" >> clause (if you use mapping). >> This is extension of mapping of modules in conf.xml. >> So, for example, I'd pursue another purpose. I'd autogenerate xquery >> modules from different >> XML declarations and store them in some temporory collections. I want >> import this modules, >> but I wan't know where them stored! And this solution is do it. >> >> This is not the replacement of "at-relative". >> >> -- >> Evgeny > > > ------------------------------------------------------------------------------ > > > _______________________________________________ > Exist-development mailing list > Exi...@li... > https://lists.sourceforge.net/lists/listinfo/exist-development > > |
From: Evgeny G. <gaz...@gm...> - 2010-05-31 09:23:07
|
2010/5/31 Joe Wicentowski <jo...@gm...>: > Evgeny - Cool. I am looking forward to giving these new functions a > try. I think Dannes asked for unit tests too - something I think is > necessary to ensure the functions can stay in trunk. Could you > contribute unit tests when you have the chance? Also is there a > deregister/unmap function, or only a register function? Just eXist have two terms - "registered" and "mapped" modules. Registered are the system modules, implemented on Java, and any imported modules into context. Mapped are modules which are statically mapped to a source location in the configuration file. This does not include any built in modules. util:map-module($namespace, $location) - allow you add namespaes of modules in this map. Is "unmap" the good term to remove namespace from map? -- Evgeny |
From: Dannes W. <da...@ex...> - 2010-05-31 06:23:49
|
Hi, On Mon, May 31, 2010 at 2:00 AM, Joe Wicentowski <jo...@gm...> wrote: > Evgeny - Cool. I am looking forward to giving these new functions a > try. I think Dannes asked for unit tests too - something I think is > necessary to ensure the functions can stay in trunk. Could you > contribute unit tests when you have the chance? Also is there a > deregister/unmap function, or only a register function? jUnit tests are really required. Probably if no tests are provided we'll need to remove the new functions again. This thing is: I am pretty sure the 'good weather behavior' is okay, but since this function introduces some dynamics, which can be rather complex, there are risks. Scenarios like - a module is registered but does not exist. What should happen? How is the user informed when things do not work? - what happens if a module is registered successfully, is successfully used for some time and then it is removed or unmapped? How can we deal with this in a production environment? All in all I think we are not done yet, there is work to do. Maybe the function is introduces too quickly. I did not see a 'go' from the core dev team, only 'some' discussions for one or 2 days on the ML.. Before adding new functions we really need to have a 'go' of e.g. wolfgang. We really need to keep control on new functionality.... cheers Dannes -- eXist-db Native XML Database - http://exist-db.org Join us on linked-in: http://www.linkedin.com/groups?gid=35624 |
From: Evgeny G. <gaz...@gm...> - 2010-05-31 06:42:39
|
2010/5/31 Dannes Wessels <da...@ex...>: > - a module is registered but does not exist. What should happen? How > is the user informed when things do not work? This is equal to situation when you import into you xquery a module with "at" clause refered to non existen module. > - what happens if a module is registered successfully, is successfully > used for some time and then it is removed or unmapped? How can we deal > with this in a production environment? Same case: you are use "at" clause when import module and then remove inported module. And you always can use "at" clause and rewrite your code every time when you tried move/rename your modules or rename colections/folders where its stored. Also you can setup your modules own in "conf.xml" "by hands" and restart eXist every time. With my functionality you can automate this pocess via triggers (new implementation of them is ready year ago, but I see that community not requried in it), xqdoc and scheduler. -- Evgeny |