[xmlblaster-devel] Unifying property names #3 - PLEASE VOTE

[Marcel Ruff <mr at marcelruff.info>]

Hi again,


here are some approaches concerning the administrative hierarchy
which completely shows the internal structure of xmlBlaster AND
forces all xmlBaster useres to use for administration/configuration.

CHANGE to #2: XPath [4] has no numNode, clientList etc anymore
             as this can be calculated by XPath (Konrad Krafft)

The first 3 approaches are SML (simple markup language without attributes):


[1] Leave as is
---------------

  http://www.xmlblaster.org/xmlBlaster/doc/requirements/admin.commands.html

Relative name:

 queue/cb/maxEntries=1000


Absolute name:

 /node/heron/client/joe/2/queue/cb/maxEntries=1000



[2] Add a <session> tag to always have a className/instanceName pair
--------------------------------------------------------------------
  e.g. className=node and instanceName=heron
  e.g. className=client and instanceName=joe
  e.g. className=session and instanceName=2

<node>
 <numNodes>3</numNodes>
 <nodeList>heron,frodo,bilbo</nodeList>
 <heron>
   <uptime>34935</uptime>
   <clientList>joe,jack,averel</clientList>
   <client>
     <joe>
       <sessionList>2,6,8,12</sessionList>
       <session>
         <2>
          <uptime>212</uptime>
          <queue>
             <cb>
               <maxEntries>1000</maxEntries>
             </cb>
          </queue>
         </2>
       </session>
     </joe>
   </client>
 </heron>
 <frodo>
 </frodo>
</node>

Relative name:

 queue/cb/maxEntries=1000


Absolute name:

 /node/heron/client/joe/session/2/queue/cb/maxEntries=1000




[3] Fix nodeList and numNodes tags to be not on nodeInstanceName level
----------------------------------------------------------------------

The nodeList and numNodes tags are on same level as the cluster node names
so choosing a cluster name='numNodes' will cause problems.
By introducing a higher root tag we resolve it:

<xmlBlaster>
<numNodes>3</numNodes>
<nodeList>heron,frodo,bilbo</nodeList>
<node>
  <heron>
    <uptime>34935</uptime>
    <clientList>joe,jack,averel</clientList>
    <client>
      <joe>
        <sessionList>2,6,8,12</sessionList>
        <session>
          <2>
            <uptime>212</uptime>
            <queue>
              <cb>
                <maxEntries>1000</maxEntries>
              </cb>
            </queue>
          </2>
        </session>
      </joe>
    </client>
  </heron>
  <frodo>
  </frodo>
</node>
</xmlBlaster>


Relative name:

queue/cb/maxEntries=1000


Absolute name:

/xmlBlaster/node/heron/client/joe/session/2/queue/cb/maxEntries=1000



[4] Choosing a pure XPath approach with attributes:
___________________________________________________


<xmlBlaster>
 <node id='heron'>
   <uptime>34935</uptime>
   <client id='joe'>
     <session id='2'>
       <uptime>212</uptime>
       <queue id='cb'>
         <maxEntries>1000</maxEntries>
       </queue>
     </session>
   </client>
 </node>
</xmlBlaster>


Relative name:

//queue[ at id='cb']/maxEntries=1000


Absolute name:


/xmlBlaster/node[ at id='heron']/client[ at id='joe']/session[ at id='2']/maxEntries=1000



NOTE:
-----

The relative and absolute names need to be used

o On command line
o In xmlBlaster.properties
o With telnet administration
o With administrative messages
o In a coming SWING GUI with a tree view on left hand side
o From a browser URL
o Using SNMP
o Using JMX
o QoS markup

NOTE 2:
-------

Using user given clusterNode names and login names and topic names
as XML markup tags is dangerous as you may not use special
characters like ':'.
Using literal names in XML attributes (see [4]) is a bit less limited
but still using a '"' or '\n' can cause problems.


any comments or votes?

regards,

Marcel


PS: See last two mail for the start of this discussion


PPS: !!Please vote for your favourite!!


PPPS: To influence the vote:

o I prefer [2], because it fixes an inconsitency from [1]

o [3] adds a root level which makes the hierarchy deeper again
  but allows a very simple DTD

o [4] is XPath centric, i personally like it very much but
  i doubt it looks nice in xmlBlaster.properties or on command line.
  Some administrators will probably be shocked.
  Mapping from SNMP etc. may be more complicated because of using 
attributes