[openi18n-im:01534] Re: path name mapping rule (Re: Feature is frozen)

[DRAFT3]  Path Name Mapping Rule  [DRAFT3]


This path name mapping rule will be defined in external
configration file based on XML, and the logic will be impelemted
in fop_path_to_uri().  fop_path_to_uri() accepts path name which
can be either of an absotule path and a relative path.


A mapping rule is defined as a series of PATHURI elements.

PATHURI is comprised of two types of elements:

  PATH   URI


  PATHURI has one of the following target:

    LE: to access files not related to a specific user
    DESKTOP: to access files related to a specific user

  PATHURI has optional attributes:

    LENAME: language engine name
    USER: user name
    XDISPLAY: X display name from which a user access the server
    CLIENTNODE: node from which a user access the server


PATH

  PATH is a path name which can include wild card characters and
  predefined macros.  This path name is compared with path names
  that are passed through the API.  If a path name through the
  API starts with "///", the mapping will not performed to the
  path name.

  Wild card characters:

    "*": matches any number of characters excluding "/".
    "**": matches any number of characters including "/".

  Macros:

    ${LENAME}: matches to a language engine name
    ${USER}: matches to a user name
    ${XDISPLAY}: matches to a X display name
    ${CLIENTNODE}: matches to a client node name


URI

  URI is a uri which is represented as SCHEME:STRING.  SCHEME is
  a scheme which interprets STRING and provide a method to
  access the file.  STRING can include predefined macros.

  SCHEME:

    file: IIIMF server directly access files.
    client: IIIMF server access files through file operation
	    agent program (iiim-fop), which runs on client side,
	    using IM_FILE_OPERATION protocol message.

  Macros:

    ${LENAME}: expanded to a language engine name
    ${USER}: expanded to a user name
    ${XDISPLAY}: expanded to a X display name
    ${CLIENTNODE}: expanded to a client node name
    ${FILE}: expanded to the last path component of the path
    ${PPATH}: expanded to the path name which is the result of
	      removal of LEADINGDIR from the original path name.
    ${OPATH}: expanded to the original path name.

  URI has optional attributes.
  
    DESKTOPSERVER:
	True when IIIMF server is running to serve a specific
	user or desktop.  False when IIIMF server is running to
	serve multiple users.
    LEADINGDIR:
	When this attribute is specified, the value must match
	the path.  This directory will be removed from the path.
    REQUIREURI:
        A uri (directory) specified by this attribute will be
	created automatically prior to the access to the mapped
	path name.

  When the scheme is "file", which is a built-in default scheme,
  it can be omitted.


Simple example (default)

    <PATHURI target="DESKTOP">
      <PATH>
        "**"
      </PATH>

      <URI desktopserver="false"
	   leadingdir="/var/lib/iiim/le/${LE}/users"
	   requireuri="client:${LE}/users">
        "client:${LE}/users/${PPATH}"
      </URI>

      <URI desktopserver="false">
        "client:${LE}/${OPATH}"
      </URI>

      <URI desktopserver="false" leadingdir="/">
        "${OPATH}"
      </URI>

      <URI desktopserver="false"
	   requireuri="/var/lib/iiim/le/${LE}/users/${USER}">
        "/var/lib/iiim/le/${LE}/users/${USER}/${OPATH}"
      </URI>

      <URI desktopserver="true"
	   leadingdir="/var/lib/iiim/le/${LE}/users"
	   requireuri="${LE}/users">
        "${LE}/users/${PPATH}"
      </URI>

      <URI desktopserver="true">
        "${LE}/${OPATH}"
      </URI>
    </PATHURI>

    This rule matches to all path names.

    Let's assume "/var/lib/iiim/le/unit/users/hoge/data" is
    specified as the path name.  "hoge" is a user name, and
    "unit" is an LE name.

    When the server is running as a shared server, and if
    IM_FILE_OPERATION is enabled for the user, the path name
    will be mapped to "client:unit/users/hoge/data".  This means
    that the scheme "client" will be used to access the file,
    and the path "unit/users/hoge/data" will be passed to
    iiim-fop, which implements "client" scheme.  iiim-fop will
    concatenete "${HOME}/.iiim/le/" and the path name, so the
    real path name will be
    "${HOME}/.iiim/le/unit/users/hoge/data".
    

    When the server is running as a shared server, and if
    IM_FILE_OPERATION is not enabled, the path name will be
    mapped to the original path name.  The scheme to access the
    file will be "file", which is implemented in iiimd.

    When the server is running as a personal server for a
    desktop, then the path will be mapped to
    "unit/users/hoge/data".  The scheme to access the file will
    be "file", which is implemented in iiimd.  iiimd will
    concatenete "${HOME}/.iiim/le/" and the path name, so the
    real path name will be
    "${HOME}/.iiim/le/unit/users/hoge/data".

    Now assume "data" is specified as the path name.  "hoge" is
    a user name, and "unit" is an LE name.

    When the server is running as a shared server, and if
    IM_FILE_OPERATION is enabled for the user, the path name
    will be mapped to "client:unit/data".  This means that the
    scheme "client" will be used to access the file, and the
    path "unit/data" will be passed to iiim-fop, which
    implements "client" scheme.  iiim-fop will concatenete
    "${HOME}/.iiim/le/" and the path name, so the real path name
    will be "${HOME}/.iiim/le/unit/data".

    When the server is running as a shared server, and if
    IM_FILE_OPERATION is not enabled, the path name will be
    mapped to "/var/lib/iiim/le/unit/users/hoge/data"

    When the server is running as a personal server for a
    desktop, then the path will be mapped to "unit/data".  The
    scheme to access the file will be "file", which is
    implemented in iiimd.  iiimd will concatenete
    "${HOME}/.iiim/le/" and the path name, so the real path name
    will be "${HOME}/.iiim/le/unit/data".