
=   AlexisDoc > Programming > Client Server > Project Rationale


 WHAT THE PROJECT WILL NEED
 
     Caching  and  request  size: At worst, the Alexis Server (Chakriya)
     will be hit with a container-listing request for a container parent
     to  50,000 objects(note container and object, which will eventually
     become  directory  and  file).  It needs to be able to respond at a
     reasonable speed to such requests, and also to provide optimisation
     features  with  respect to the projected client cache so that these
     events should only happen once in an individual user's lifetime.

     Links: All sorts of information will be linked in all sorts of ways
     -  for  instance,  50,000  dictionary entries will be linked to one
     DTD,  and  through  that to various CSS stylesheets, XSL transforms
     and application-specific UI configuration files. Rather than have:

     <?xml version="1.0" encoding="UTF-8"?>

     <?link type="css">

     <de
     xmlns:"http://ella-associates.com/alexis/app1/schema/dict1.xsd"...

     ...the real content

     </de>

     it  seems  better  to have this abstracted, in the form of metadata
     attached to each XML file. The question is, then, how to attach it.

     Collation documents: 

     For  various  purposes,  one  might  want different combinations of
     dictionary entries. What I envisage is a collation document...built
     from atoms (words), in any way...

     words   beginning   with   "a"...select   *   from   entries  where
     substr(name,1)='a'

     words  of  difficulty  "x"  (i.e.  1[most  complex]  for the, 3 for
     advance,  5 for aardvaark [least complex])....select * from entries
     where difficulty=x

     that  easy. It plugs into the relational filesystem, in reality, in
     an  even  easier  way  (because you're talking about [virtual] file
     properties:  name,  difficulty,  which for even up to quite complex
     queries will hide all SQL from the client/user)

     The  collation  documents  would  be  live, and any change to nodes
     outside  the built structure (i.e. programming instructions outside
     a <DE> tag, <DE> being dictionary entry) would cause it to become a
     final  document,  which  could  be live or not, but would no longer
     allow   changes  to  its  structure  through  manipulation  of  the
     underlying SQL/file property search.

     Different access models: (new)

     The  fundamental  reason  for  relational filesystems is to provide
     different  access  models for different end-user situations, rather
     than  tying  them to one structure. This is often accomplished in a
     half-assed way (viz. Windows favourites (sic, them) and documents),
     but  in a project like this where administrators (managing editors)
     need  to  see the raw, unstructured dataset, and editors would need
     different access structures depending on whether they were browsing
     or  editing dictionary entries. Additionally, the client and server
     both  need  "back-door"  access  to  resources  which  define their
     operation, all stored on the same system.

     In  fact,  a relational filesystem, or an unconcious implementation
     of  one  occurs  any  time access occurs with the accessor (user or
     computer)  wearing  different  hats: again, think of the "physical"
     location of the desktop/my documents folders on an NT/9x partition.

     The  reason  for  a  formalisation of this for Alexis is because we
     have  a  four-tier (system, managing editor, senior editor, editor)
     user  hierarchy,  each  of  whom  will  have  different  (sometimes
     overlapping)  access  priorities,  in  a  networked environment (so
     synchronisation  of  resource  access  protocols  is  exceptionally
     important), and because we're dealing with at times large datasets.

 WHAT THE ALTERNATIVES ARE

     This splits two ways: protocol and repository

     1. Protocol
     This could be an extension of WebDAV, with special encodings in the
     XML/properties  section of the request to provide support for cache
     levels and other app-specific items. 

     There  aren't  really  any  reasons not to do this, but leave it to
     revision  1  at  least.  There  is  a  problem with multiple-object
     transfers,  basically  it may take webDAV a year or two to get to a
     reasonable  point  for  implementing  the  idea  of "one big zipped
     transfer".  Until  then, I'll try and keep the conceptual framework
     of the communication protocol as similar as possible, so as to ease
     transfer   (although,   that   given,   the  limitation  of  actual
     protocol-handling  to  a couple of classes means this won't be that
     difficult.

     Anything  else,  such  as FTP or frontpage extensions, seems like a
     waste of time.

     For some links on webDAV: http://www.webdav.org

     ummm...yeah,  LDAP  or  JNDI...must  have  a look at them too. Will
     probably  be  a lot of crossover between them, Active Directory and
     webDAV as time goes on...a unified protocol?? Can be left, anyway.

     2. Repository
     Trickier. For an overview of comparative difference:

     http://www.rpbourret.com/xml/XMLAndDatabases.htm (5 stars from me)

     an index: http://www.searchtools.com/info/xml-resources.html

     Basically,  from  what  I  can  see  an  XML  (native or otherwise)
     database has two parts: front end (how it serves the data) and back
     (how it stores and indexes it). For probably the best:

     http://www.softwareag.com/tamino/

     But,  unfortunately, the idea is to store large documents and serve
     editable  parts of the document. They're general, in a lot of cases
     much  slower  than  relational-, and quite inflexible...because the
     unit  of  data they're designed for is quite large (document). They
     also  wouldn't  adapt  well to relational filesystem concept, since
     too  much  of  the  data  is  stored  below  the  waterline (in the
     document) rather than simple-access-external.

     It comes down to two things: the targeted data (lots of little flat
     things)   and  the  desired  access  hierarchy  (potentially  quite
     complex,  and  certainly a user-friendly one will be lead to a hell
     of alot better user sexperience).


 HENCE THIS

     1. Custom protocol (detail)
     For  reasons of (1) caching, (2) machine load at both ends, (3) the
     fact   it's   already   half-done,   go  with  an  xml-encapsulated
     protocol...named  shamiram.  Keep  as  close  to  general thrust of
     webDav as is reasonable

     2. Relational filesystem (detail)
     A way to map a flexible hierarachy, based on characteristics of the
     file's  content,  on  top of a quite flat datastructure. See below:
     right maps to left...


 NOTES ON LDAP AND ACTIVE DIRECTORY
 
   They're protocols for accessing minimal-meta-information resource sets
   - which could, yes, be extended proprietorally.

   Overview of ldap:

   http://www.kingsmountain.com/directory/doc/ldap/3.ldap.html

   Active Directory

   Microsoft's proprietory implementation of the above. Say no more.

   Thoughts

   Notwithstanding  the above about webDAV, it could easily be thought of
   as an application-specific implementation of Ldap

   Advantages of Shamiram (protocol): XML-based, hence human readable and
   Java-friendly.  Lightweight,  because  application specfic. Integrated
   support  for resource depth (amount of info desired) and corresponding
   integration  into  permissions  structure.  Both the client and server
   must  support  the  resourceDepthProvider interface, which, as will be
   seen  in  the  schema  and  component  outlines,  is integral to their
   functionality.

   In fact, the easiest way to implement a Chakriya>LDAP Server or webDAV
   server  bridge  would  be  to  bridge  at  the  protocol,  rather than
   application  level.  As  long  as  Shamiram  is  roughly equivalent in
   functionality (which it is), just run a SAX parser>translator.


 TO DO
 
   fix my uml ideas, and refine as the thing takes greater shape

   LAST UPDATE:
   Nick Reddel
   Tuesday April 15, 2003
   
