Thanks again Geert.
I'm still confused on 2 things.

1) "Shared" Modules ...
You mention putting "Shared" Modules in a shared DB.  How can I do that
?
In the configuration for an App (HTTP or XDBC) I can only pick ONE
Modules DB (or filessystem)
So how can I have both a  "Shared" Modules DB and an app specific one ?
Or is that not what you meant ?

2) "Modules as an Object"
You mentioned using an xquery module as an object.   What do you mean by
that ?
I can think of one way.  Import the module, then every public function
in it is 'like a' static method of an object.  But are you referring to
some other design pattern ?

Thanks



-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Geert
Josten
Sent: Tuesday, December 15, 2009 7:24 AM
To: General Mark Logic Developer Discussion
Subject: RE: [MarkLogic Dev General] RE: Towards a more
modularapparchitecture...

> I guess I wasn't thinking straight.  Of course Both the HTTP and XDBC
> servers can read from the same "Modules"  DB (or filesystem).   I was
> getting confused with the difference that App server modules
> get arguments via the HTTP extensions whereas XDBC modules
> get arguments via 'declare variable external'.

Yes, HTTP and XDBC can share the same Modules DB, and same root folder
on filesystem for that matter. And they can also literally share the
same module files as well.

> I presume a typical organization is to use a directory
> structure to 'group' different types of interfaces ?
> (modules, xquery 'main' modules, App server front end etc).

People tend to organize files according to their type, but I personally
would recommend sticking to a functional organization.

> I haven't quite figured out how MarkLogic global libraries
> are addressed, like the functx library, which is outside a
> given app module directory ... Is there a way to share common
> code across App Module DB's like ML does for built-in ones ?

Yeah, MarkLogic global libraries are a bit of a special case, but they
are distributed with MarkLogic Server itself, so don't bother the
details.. ;-)

You should put you shared modules in a shared Modules database. You can
reuse the existing one, putting everything under some neat root-level
subfolder, or create a new one. Doesn't really matter much. The
advantage of using Modules database above filesystem is mainly that you
can apply security on modules in the Modules database, where as that is
not possible when storing them on filesystem. It might also allow
MarkLogic Server to cache them..

> Probably wont need that as you say the different servers can
> share the same App Modules DB.

I actually meant sharing of the module files, but yes, all app servers
in the same cluster can share these databases. To my knownledge even
when they are not in the same group..

Kind regards,
Geert


Drs. G.P.H. Josten
Consultant


http://www.daidalos.nl/
Daidalos BV
Source of Innovation
Hoekeindsehof 1-4
2665 JZ Bleiswijk
Tel.: +31 (0) 10 850 1200
Fax: +31 (0) 10 850 1199
http://www.daidalos.nl/
KvK 27164984
De informatie - verzonden in of met dit emailbericht - is afkomstig van
Daidalos BV en is uitsluitend bestemd voor de geadresseerde. Indien u
dit bericht onbedoeld hebt ontvangen, verzoeken wij u het te
verwijderen. Aan dit bericht kunnen geen rechten worden ontleend.



_______________________________________________
General mailing list
[email protected]
http://xqzone.com/mailman/listinfo/general
_______________________________________________
General mailing list
[email protected]
http://xqzone.com/mailman/listinfo/general

Reply via email to