3. Album datafiles and other object definitions

3.1. Album datafiles

Each album will have the following datafiles:

Table 3.1 Overview of album datafiles
Datafile #instances Existence checked by / read by PHP-function Stored in Modified by
fproc.txt 1 per album RProc_FProc_Status_X00FF0()   N.A.
rproc.txt 1 per album RProc_FProc_Status_X00FF0()    
phpdefinition.xml 1 per album CheckProcessStatus_X000FF() SimpleXMLElement object Manual
albumOverview.xml 1 for all albums AlbumCatalogue() SimpleXMLElement object Manual
iminfo.xml n per album GetIminfoObjects() SimpleXMLElement object  

These album files reside at the server-side. Updating these files as a result of user action at the client side (e.g. Fig. 2.2) will be implemented by AJAX calls. The content of xml files is stored in PHP built-in XML objects by the PHP function simplexml_load_file().

3.1.1. fproc.txt

Each processed album has in its root directory file fproc.txt. It is an empty file, and its purpose is to lock the album content when the administrator or album owner is logged on: i.e. no new media will be processed when visiting the album. When this file is deleted, the album is unlocked so automatic updating can be executed. The file can only be deleted by administrator or album owner.

3.1.2. rproc.txt

Each processed album has in its root directory file rproc.txt. The purpose of this file is to give a media count overview (i.e. photographs and videos) in each location directory and to have a fast overview of album, and how the media are divided over the public and private directories.

  1. First column: directory name,
  2. Second column: total number of media,
  3. Third column: total number of public media,
  4. Fourth column: total number of private media.

Video media with the same basename but with different extensions (i.e. same video with different formats/codecs), are considered as different media. The same information can be derived from all IMINFO.XML files, but then these files need to be processed and that requires process time (note that IMINFO.XML distinguishes between photographs and videos). The last row contains the sum of all media. An example of a rproc.txt file is given in Table 3.2. The last row is the sum of media in all location directories.

Table 3.2 Example of rproc.txt file content.
DeReis 17 12 5
Weeshuis 13 13 0
HoChiMinh 74 68 6
DaguitHCM-TayNinh 19 16 3
DaguitHCM-Mekong 21 16 5
Mui Ne 56 44 12
Dalat 57 50 7
Nha trang 21 19 2
Hoian 88 85 3
Hue 94 90 4
Hanoi 52 48 4
Halong Bay 13 12 1
* 525 473 52

3.1.3. phpdefinition.xml

The album is regular if the file phpdefinition.xml exists. It has sub-directories to provide structure to the album, with names given in this file and optional descriptions. Examples of phpdefinition.xml files are given in Listing 3.1 (without location descriptions) and Listing 3.2 (with location descriptions: has tag elements <HeeftBeschrijvingen> and <verslag>). When the file phpdefinition.xml does not exist, the album has a “simple” structure: media in all sub-directories (recursively with directory depth 1) are used for the album. As it is an album definition file it cannot be updated automatically. Any update should be done manually by administrator or album owner. In principle any text editor will do for modifying the file phpdefinition.xml.

Listing 3.1 Example content of file phpdefinition.xml without descriptions. The number of <directory> tag elements must be content consistent with file rproc.txt, i.e. with the number of rows - 1.
<album>
   <directory>
     <name>DeReis</name>
     <thumb_caption>De Reis</thumb_caption>
   </directory>
   <directory>
     <name>Weeshuis</name>
     <thumb_caption>Het weeshuis</thumb_caption>
   </directory>
   <directory>
     <name>HoChiMinh</name>
     <thumb_caption>Ho Chi Minh City</thumb_caption>
   </directory>
   <directory>
     <name>DaguitHCM-TayNinh</name>
     <thumb_caption>Daguit naar TayNinh</thumb_caption>
   </directory>
   <directory>
     <name>DaguitHCM-Mekong</name>
     <thumb_caption>Daguit naar Mekong</thumb_caption>
   </directory>
   <directory>
     <name>Mui Ne</name>
     <thumb_caption>Mui Ne</thumb_caption>
   </directory>
   <directory>
     <name>Dalat</name>
     <thumb_caption>Dalat</thumb_caption>
   </directory>
   <directory>
     <name>Nha Trang</name>
     <thumb_caption>Nha Trang</thumb_caption>
   </directory>
   <directory>
     <name>Hoian</name>
     <thumb_caption>Hoian</thumb_caption>
   </directory>
   <directory>
     <name>Hue</name>
     <thumb_caption>Hue</thumb_caption>
   </directory>
   <directory>
     <name>Hanoi</name>
     <thumb_caption>Hanoi</thumb_caption>
   </directory>
   <directory>
     <name>Halong Bay</name>
     <thumb_caption>Halong Bay</thumb_caption>
   </directory>
 </album>
_images/Fig18_DirectoryThumbs.png

Fig. 3.1 Directory thumbs without descriptions.

Listing 3.2 Example content of file phpdefinition.xml with tag element <verslag>, to be used when <HeeftBeschrijvingen> 1</HeeftBeschrijvingen>.
<?xml version="1.0" encoding="utf-8"?>
<album>
  <HeeftBeschrijvingen>1</HeeftBeschrijvingen>
  <directory><name>12 juni 2011</name><thumbIcon></thumbIcon>
  <thumb_caption>Zondag 12 juni</thumb_caption>
  <verslag> Zondag, Bagnères de Louchon:Port de Balès (klim vanuit noordzijde), Super Bagnères (<b>130km, 2850
    hoogtemeters</b>). Zoals het plaatje bij de pauze laat zien is het weer prachtig. Eerste 40 km zijn relatief vlak
    zodat we er op het eind van de dag gratis 450 hoogtemeters bij hebben gekregen vooraleer we aan de 18km lange beklimming
    begonnen van de Port de Balès. ...
  </verslag>
  </directory>
  <directory><name>13 juni 2011</name><thumbIcon></thumbIcon>
  <thumb_caption>Maandag 13 juni</thumb_caption>
  <verslag>Maandag, Bagnères de Louchon: Portillon (klim westzijde), Mente (klim westzijde), Portet d&#39;Aspet (klim
    westzijde): <b>116km, 2380 hoogtemeters</b>. Meteen bij het uitrijden van Bagnères de Louchon begint de 11km lange klim
    van de Portillon richting Spanje. Na de afdaling had Hans wederom een lekke band. Om er zeker van te zijn dat de band
    ditmaal wel goed werd gemaakt, staken we met z&#39;n allen een handje toe. Sneller ging het echter niet. ...
  </verslag>
  </directory>
  <directory><name>14 juni 2011</name><thumbIcon></thumbIcon>
  <thumb_caption>Dinsdag 14 juni</thumb_caption>
  <verslag>Dinsdag, Bagnères de Louchon: Peyresourde (eerste klim van de dag langs de oostzijde, laatste klim van de dag
    langs de westzijde), Aspin (klim oostzijde), Hourquette (klim westzijde): <b>110km, 3150 hoogtemeters</b>. Peyresourde
    en Aspin zijn welbekende gedienden in de Tour. De Hourquette daarentegen is pas in 2011 in het bergarsenaal van de Tour
    opgenomen. In de Tour 2011 was de Hourquette (klim langs oostzijde) een opwarmertje voor de Tourmalet. ...
  </verslag>
  </directory>
  <directory><name>15 juni 2011</name><thumbIcon></thumbIcon>
  <thumb_caption>Woensdag 15 juni</thumb_caption>
  <verslag>Woensdag: Na het ontbijt werden de auto's snel ingeladen en werd er naar het volgende verblijf gereden:
    Argelès-Gazost. Na het uitladen aldaar ging het grootste deel van de groep naar het welbekende nabijgelegen bedevaartsoord
    Lourdes. De anderen fietsten de geplande route naar Col de Tentes (<b>99km, 1604 hoogtemeters</b>). Dit is waarschijnlijk
    een minder bekende col die vanuit Luz-Saint-Saveur te bereiken is. ...
  </verslag>
  </directory>
  <directory><name>16 juni 2011</name><thumbIcon></thumbIcon>
  <thumb_caption>Donderdag 16 juni</thumb_caption>
  <verslag>Donderdag, Argelès-Gazost: Aubisque (<b>115km, 1500 hoogtemeters</b>).
  </verslag>
  </directory>
  <directory><name>17 juni 2011</name><thumbIcon></thumbIcon>
  <thumb_caption>Vrijdag 17 juni</thumb_caption>
  <verslag>Vrijdag, Argelès-Gazost: Tourmalet, Hautacam (<b>135km, 3300 hoogtemeters</b>). Door een locale rittenwedstrijd
    die toevallig ook vandaag over de Tourmalet ging op het tijdstip dat we die ook zouden doen moesten we de geplande route
    om te draaien. Hierdoor beklommen we Tourmalet in de ochtend vanuit de westzijde (Luz-Saint-Saveur) voordat deze zou worden
    afgesloten voor de wedstrijd in plaats vanuit Saint Marie de Campan. Bovenop de Tourmalet was het zoals gewoonlijk een
    drukte van jewelste. De wind joeg ons de herberg in om daar een lekkernij met warme drank te nuttigen. ...
  </verslag>
  </directory>
</album>
_images/Fig18_DirectoryThumbs+Description.png

Fig. 3.2 Directory thumbs with descriptions.

3.1.4. albumOverview.xml

File albumOverview.xml contains an overview of all albums. Each album is represented as an element with the following child nodes:

  • <Name>: Name of the album.
  • <Directory>: Directory relative to the document root.
  • <Owner>: Owner of the album. Possible values are given by the Group enumeration values (see Table members of the users database in MySQL, and Table 1.5). The value is used to determine which users have the permission view the private version of an album, and the permission to edit the album. For example if <Owner>famile</Owner> then only registered users belonging to the familie Group can edit and view the album.
  • <Description>: Short description of the album.
  • <CreationDate>: Creation date of the album.
  • <ID>: Unique identification number.

3.1.5. Source code

Listing 3.3 Current content of albumOverview.xml.
<?xml version="1.0" encoding="utf-8"?>
<AlbumOverview>
  <Album>
    <Name>Vietnam 2008</Name>
    <Directory>reizen/2008 Vietnam</Directory>
    <OwnerLevel>Group</OwnerLevel>
    <Owner>familie</Owner>
    <Description>Zomervakantie 2008</Description>
    <CreationDate>Augustus 2008</CreationDate>
    <ID>1</ID>
  </Album>
  <Album>
    <Name>USA 2010</Name>
    <Directory>reizen/2010 USA</Directory>
    <OwnerLevel>Group</OwnerLevel>
    <Owner>familie</Owner>
    <Description>Zomervakantie 2010</Description>
    <CreationDate>Augustus 2010</CreationDate>
    <ID>2</ID>
  </Album>
  <Album>
    <Name>Italie 2011</Name>
    <Directory>reizen/2011 Italie</Directory>
    <OwnerLevel>Group</OwnerLevel>
    <Owner>familie</Owner>
    <Description>Zomervakantie 2011</Description>
    <CreationDate>Augustus 2011</CreationDate>
    <ID>3</ID>
  </Album>
  <Album>
    <Name>Vietnam 2014</Name>
    <Directory>reizen/2014 Vietnam</Directory>
    <OwnerLevel>Group</OwnerLevel>
    <Owner>familie</Owner>
    <Description>Zomervakantie 2014</Description>
    <CreationDate>Augustus 2014</CreationDate>
    <ID>4</ID>
  </Album>
  <Album>
    <Name>Kreta 2015</Name>
    <Directory>reizen/2015 Kreta</Directory>
    <OwnerLevel>Group</OwnerLevel>
    <Owner>familie</Owner>
    <Description>Zomervakantie 2015</Description>
    <CreationDate>Augustus 2015</CreationDate>
    <ID>5</ID>
  </Album>
  <Album>
    <Name>Vietnam 2016</Name>
    <Directory>reizen/2016 Vietnam</Directory>
    <OwnerLevel>Group</OwnerLevel>
    <Owner>familie</Owner>
    <Description>Zomervakantie 2016</Description>
    <CreationDate>Augustus 2016</CreationDate>
    <ID>6</ID>
  </Album>
  <Album>
    <Name>Pyreneen, juni 2011</Name>
    <Directory>dany/fiets/2011-Juni Pyreneen</Directory>
    <OwnerLevel>User</OwnerLevel>
    <Owner>dany</Owner>
    <Description>Fietsvakantie 2011</Description>
    <CreationDate>Juni 2011</CreationDate>
    <ID>7</ID>
  </Album>
  <Album>
    <Name>La Mure, juni 2012</Name>
    <Directory>dany/fiets/2012-Juni LaMure</Directory>
    <OwnerLevel>User</OwnerLevel>
    <Owner>dany</Owner>
    <Description>Fietsvakantie 2012</Description>
    <CreationDate>Juni 2012</CreationDate>
    <ID>8</ID>
  </Album>
  <Album>
    <Name>Tarn, juni 2013</Name>
    <Directory>dany/fiets/2013-Juni Tarn</Directory>
    <OwnerLevel>User</OwnerLevel>
    <Owner>dany</Owner>
    <Description>Fietsvakantie 2013</Description>
    <CreationDate>Juni 2013</CreationDate>
    <ID>9</ID>
  </Album>
</AlbumOverview>

3.1.6. iminfo.txt

First file format to store info of media (comma separated format). It is text file where each line represents a media file. A typical example is given in Listing 3.4. Each line has a fixed number of data entries:

  • Column 1: media filename after processing (in general down sizing),
  • Column 2: original filename (in location directory),
  • Column 3: timestamp (date and time format),
  • Column 4: UNIX timestamp format: more convenient for ordening,
  • Column 5: R (public) or Private,
  • Column 6: Horizontal pixel number in original media file
  • Column 7: Vertical pixel number in original media file
  • Column 8: Horizontal resolution
  • Column 9: Vertical resolution
Listing 3.4 Structure of an iminfo.txt file.
0000-IMAG2917-small.jpg,IMAG2917.JPG,2008:07:21 01:40:34,1216597234,R,2560,1920,72/1,72/1,
0001-IMAG2918-small.jpg,IMAG2918.JPG,2008:07:21 01:52:36,1216597956,R,1920,2560,72/1,72/1,
0002-IMAG2929-small.jpg,IMAG2929.JPG,2008:07:21 04:40:58,1216608058,Private,1920,2560,72/1,72/1,

A switch was made to another format (see Section 3.1.7), which was more flexible with respect to future extensions, and which has possibilities for internal structure.

3.1.7. iminfo.xml - iminfo object

If the album file phpdefinition.xml exists, each location directory must have a file called iminfo.xml, containing information of each media in the location directory. The xml file global structure is given in Listing 3.5. As mentioned in Section 3.1, the content of an iminfo.xml is stored in an object of class SimpleXMLElement <https://www.php.net/manual/en/class.simplexmlelement.php> by the PHP function simplexml_load_file(). When new media is added and or media is removed from an album in a location directory, the iminfo.xml file in that location directory can be updated automatically by administrator or album owner (see paragraph Section 3.2.2).

Listing 3.5 Structure of an iminfo.xml file.
<?xml version="1.0" encoding="utf-8"?>
<directory>
  <media>…</media>
  <media>…</media>
  <media>…</media>
  …
  <media>…</media>
  <ImageInfo> … </ImageInfo>
  <VideoInfo> … </VideoInfo>
  <MediaCounterInfo> … </MediaCounterInfo>
  <Version> … </Version>
</directory>

There are 2 types of media: image and video. The image and video media tags only differ in their <MIMETYPE> tag element (see sections Section 3.1.7.1 and Section 3.1.7.2). The tag elements <ImageInfo> and <VideoInfo> contain information about the numbers of images and videos, respectively. Description of the tag elements <ImageInfo> and <VideoInfo> are given in Section 3.1.7.4, and Section 3.1.7.5, respectively.

3.1.7.1. Example Image media tag

Listing 3.6 Code of media element for image type.
<media>
   <Selected>1</Selected>
   <TimeSortedFile> 0021-P6130094-small.jpg</TimeSortedFile>
   <OriginalFile> P6130094.JPG</OriginalFile>
   <TimeString> 2011:06:13 15:10:03</TimeString>
   <TimeStamp> 1307970603</TimeStamp>
   <PublicPrivate> R</PublicPrivate>
   <Transferred2SiteDir> 1</Transferred2SiteDir>
   <Width>4288</Width>
   <Height>3216</Height>
   <XResolution>72/1</XResolution>
   <YResolution>72/1</YResolution>
   <GPSLongitude>0.66046715003498</GPSLongitude>
   <GPSLatitude>42.977415539993</GPSLatitude>
   <MIMETYPE>
      <IMAGE>
         <BASENAME>P6130094</BASENAME>
         <TYPE ext="JPEG">1</TYPE>
      </IMAGE>
   </MIMETYPE>
   <Count>1</Count>
 </media>

An explanation of tag element <Transferred2SiteDir> and possible values are given in section Section 2.1.7.

3.1.7.2. Example Video media tag

Listing 3.7 Code of media element for video type.
<media>
   <Selected>1</Selected>
   <TimeSortedFile>12-Juni-pause1.mp4</TimeSortedFile>
   <OriginalFile>12-Juni-pause1.mp4</OriginalFile>
   <TimeString> </TimeString>
   <TimeStamp>1485863183</TimeStamp>
   <PublicPrivate> R</PublicPrivate>
   <Transferred2SiteDir>-1</Transferred2SiteDir>
   <Width>640</Width>
   <Height>360</Height>
   <XResolution>0</XResolution>
   <YResolution>0</YResolution>
   <GPSLongitude>NO-LNG</GPSLongitude>
   <GPSLatitude>NO-LAT</GPSLatitude>
   <MIMETYPE>
      <VIDEO>
         <BASENAME>12-Juni-pause1</BASENAME>
         <TYPE ext="WEBM">1</TYPE>
         <TYPE ext="MP4">1</TYPE>
      </VIDEO>
   </MIMETYPE>
   <Count>2</Count>
 </media>

3.1.7.3. Example General media info tag

Images and video have the following general info tags:

Table 3.3 General info tags for images and video.
Info tag Video / image Purpose of tag / description
<HasImage> Image + video Boolean
<ReleasedCount> Image + video Total number of released public and private images or videos.
<Rel_PublicCount> Image + video Number of released public images or videos.
<Rel_PrivateCount> Image + video Number of released private images or videos.
<Rel_PublicFilesCount> Video number of released public video files.
<Rel_PrivateFilesCount> Video number of released private video files.
<Trf_PublicCount> Image + video Number of images or videos to be transferred to public directory.
<Trf_PrivateCount> Image + video Number of images or videos to be transferred to private directory.
<PublicCount> Image + video Total number of public images or videos.
<PublicFilesCount> Video Total number of public video files.
<PrivateCount> Image + video Number of private iamges or videos.
<PrivateFilesCount> Video Total number of private video files.

3.1.7.4. Example General image info tag

Listing 3.8 Code of ImageInfo element.
<ImageInfo>
   <HasImage>1</HasImage>
   <TransferCount>22</TransferCount>
   <TransferCountPublic>22</TransferCountPublic>
   <TransferCountPrivate>0</TransferCountPrivate>
   <PublicCount>22</PublicCount>
   <PrivateCount>0</PrivateCount>
</ImageInfo>

3.1.7.5. Example General video info tag

Listing 3.9 Code of VideoInfo element.
<VideoInfo>
   <HasVideo>1</HasVideo>
   <TransferCount>1</TransferCount>
   <TransferCountPublic>1</TransferCountPublic>
   <TransferCountPrivate>0</TransferCountPrivate>
   <TransferFilesCountPublic>2</TransferFilesCountPublic>
   <TransferFilesCountPrivate>0</TransferFilesCountPrivate>
   <PublicCount>2</PublicCount>
   <PublicFilesCount>4</PublicFilesCount>
   <PrivateCount>0</PrivateCount>
   <PrivateFilesCount>0</PrivateFilesCount>
   <VideoWidth>640</VideoWidth>
   <VideoHeight>360</VideoHeight>
</VideoInfo>

3.2. Album datafiles update approach

3.2.1. Normal user

Table 3.4 Update methods for album datafiles: normal user. Under normal conditions no album files will be updated, except when rproc.txt is accidentally deleted.
File #files Update method Update info
fproc.txt 1 per album NONE As “normal” user the file fproc.txt cannot be deleted, meaning that the album is locked.
rproc.txt 1 per album Automatic

Automatic regeneration by function RProc_FProc_Status_X00FF0(): see also Table 3.5

  • File rproc.txt exists: no update takes place.
  • File rproc.txt does not exist: Under normal this should not occur. If by accident this file is deleted rproc.txt is created with the info from all iminfo.xml files.
phpdefinition.xml 1 per album NONE No update will take place.
iminfo.xml 1 per location NONE No update will take place.
Table 3.5 Update actions as normal user on files fproc.txt and rproc.txt implemented in function RProc_FProc_Status_X00FF0().
RProc_FProc_Status_X00FF0() fproc exists rproc exists fproc action rproc action Remark
NO_PROCESSED_FILES (0x0000) 1 1/0 Do nothing    
PROCESSED_FILES_ORIGINALS_KEPT
(0x0001)
 1 0 Do nothing Regenerate When rproc.txt is accidentally removed by a file manager
1 1 Do nothing Read rproc.txt  
PROCESSED_FILES_ORIGINALS_ADD_REM
(0x0002)
 1 0 Do nothing Regenerate When rproc.txt is accidentally removed by a file manager
1 1 Do nothing Read rproc.txt  
PROCESSED_FILES_ORIGINALS_REMOVED
(0x0003)
 1 0 Do nothing Regenerate When rproc.txt is accidentally removed by a file manager
1 1 Do nothing Read rproc.txt  
_images/Fig_DialogMsgBox_MediaProcessStatus_NormalUser.png

Fig. 3.3 Media Processing Status dialog window for “normal” user. When an album change is detected, which would require an album update a dialog box will pop up. When “STATUS WINDOW” is selected the normal user can see what changes have been detected. When selecting “LOGIN” the normal user change switch to album owner or “admin” in order to proceed with the album update process. For more details see also Section 4.4.1.2.

3.2.2. Album owner / administrator

Table 3.6 Update methods for album datafiles: administrator.
File #files
Update
method
 Update info
fproc.txt 1 per album NONE When deleted the update process is started. The file fproc.txt is deleted when pressing the “OK” button in the media processing status dialog box (see Fig. 3.4). The file itself cannot be updated since it is an empty file. When the update process is completed the file fproc.txt is created again (by RProc_FProc_Status_X00FF0()) so that the album is locked.
rproc.txt 1 per album Automatic
In the current implementation approach rproc.txt is updated in 2 phases.
Phase 1: RProc_FProc_Status_X00FF0(), which is the same as for “normal” user (see also See Table 3.7).
Phase 2:
  • 0x00F00: see also Table 2.4 for a description what type of modification has taken place. This is communicated in the media process status dialog box (see Fig. 2.2).
  • In the actual updating process (initiated when fproc.txt is deleted), when all iminfo.xml files have been updated, rproc.txt will be updated using the updated iminfo.xml files by an AJAX call (AnalyseDeletedAndNewMedia() implemented in js\myjs\public_private.js) to php\analyse_status_table.php.
  • The info in |F|F|●●●1|F|F| itself is not used for updating rproc.txt file.
  • Only administrator can update this file.
phpdefinition.xml 1 per album NONE Must be modified by using text editor (i.e. not automatic update). A user interface can be developed to edit phpdefinition.xml.
iminfo.xml 1 per location NONE Only administrator/album owner can initiate the update process of iminfo.xml files, by deleting the file fproc.txt.
Table 3.7 Actions on files fproc.txt and rproc.txt implemented in function RProc_FProc_Status_X00FF0().
Rproc_Fproc_Status_X00FF0() fproc exists rproc exists fproc action rproc action Remark
NO_PROCESSED_FILES(0x0000) 1 1/0 Delete    
0 1/0 Create Regenerate  
PROCESSED_FILES_ORIGINALS_KEPT (0x0001) 0 0 Create Regenerate  
0 1 Create Read rproc.txt  
1 0 Do nothing Regenerate rproc.txt is removed by filemanger
1 1 Do nothing Read rproc.txt  
PROCESSED_FILES_ORIGINALS_ADD_REM (0x0002) 0 0 Create Regenerate  
0 1 Create Read rproc.txt  
1 0 Do nothing Regenerate rproc.txt is removed by filemanger
1 1 Do nothing Read rproc.txt  
PROCESSED_FILES_ORIGINALS_REMOVED (0x0003) 0 0 Create Regenerate  
0 1 Create Read rproc.txt  
1 0 Do nothing Regenerate rproc.txt is removed by filemanger
1 1 Do nothing Read rproc.txt  
_images/Fig_DialogMsgBox_MediaProcessStatus_Admin.png

Fig. 3.4 Media Processing Status dialog window for administrator. Note that there is an additional tab (“New/Removed media”). For more details see also Section 4.4.1.4.

3.3. Album main object definitions

3.3.1. Media object

Object created and initialized by InitMediaObject(), which is called at the beginning of dirThumbs(). The initialization values are given in the second column of Table 3.8. Media object is updated by CheckProcessStatus_X000FF().

3.3.1.1. Definition

Table 3.8 Description of Media object and its initialization values.
Object key Init value Comment
CountList Empty array See Table 5.4
NoMedia FALSE  
UpdateAction NO_MEDIA_PROCESSING 3rd output argument of function RProc_FProc_Status_X00FF0(). See also Section 3.3.1.2.
NewCount 0

=NewImageCnt + NewVideoCnt

Value assigned in DetailedStatusAnalysis()
NewImageCnt 0 Value assigned in DetailedStatusAnalysis()
NewVideoCnt 0 Value assigned in DetailedStatusAnalysis()
RemovedCount 0 Value assigned in DetailedStatusAnalysis()
ImInfoNT_ImageCnt 0

(NT = not transferred)

Value assigned in DetailedStatusAnalysis()
ImInfoNT_VideoCnt 0 Value assigned in DetailedStatusAnalysis()
PutBackM_ImageCnt 0 Value assigned in DetailedStatusAnalysis()
PutBackM_VideoCnt 0 Value assigned in DetailedStatusAnalysis()
PutBackM_Cnt 0 Value assigned in DetailedStatusAnalysis()

3.3.1.2. Values for UpdateAction

See also third output argument of function RProc_FProc_Status_X00FF0().

Table 3.9 Values for key UpdateAction of the Media object.
NO_MEDIA_PROCESSING (=0x00)
  • Default value: Value returned by RProc_FProc_Status_X00FF0() when both fproc.txt and rproc.txt exist.
  • Value is assigned when $session[‘caller’]===’child’.
UPD_MEDIA_PROCESSING (=0x02) Value returned by RProc_FProc_Status_X00FF0() when fproc.txt does not exist. This will result in the assignment $albumDirThumbStatHtml[‘status’][‘updateProgressDialogBox’] = true (see also Table 4.20) in the main script of php\prepareDirOverviewGalleryAjax.php, and will initiate the actual update process in JavaScript function prepareDirOverviewGallery(). See also Fig. 4.12.
ALL_MEDIA_PROCESSING (=0x01) If |F|F|F|F|●●XX|== NO_PROCESSED_FILES Value returned by RProc_FProc_Status_X00FF0() when neither fproc.txt nor rproc.txt exist (in case when the value of X0000F is equal to PROCESSED_FILES_ORIGINALS_ADD_REM or NO_PROCESSED_FILES. See also Table 2.1.

3.3.1.3. Use and scope

The object is used as data member in the AJAX interface API object albumDirThumbStatHtml_Object (see Section 4.5, and Table 4.16).

3.3.2. XFFFFF object

Instance of the object is initialized in, and returned by CheckProcessStatus_X000FF(). The values of the keys withe IP info about server side ad client side, are initialized to empty strings.

3.3.2.1. Definition

  • [‘GlobStat’]: Hexadecimal number consisting of 5 digits: see Section 2.1 and Table 4.9.
  • [‘FillStat’]: Hexadecimal mask (5 digits). The object $XFFFFF is passed as an argument in various functions. This key holds a value which indicates which digit(s) of [‘GlobStat’] are changed by the calling function. For example: in the function CheckProcessStatus_X000FF() the return value of $XFFFFF[‘FillStat’] is 0x0000F indicating that the fifth digit has been set to a value.
  • [‘permissionDeleteProcFile’]: Boolean. True when user is allowed to delete file fproc.txt. This is determined by the macro ALBUM_UPDATE_PERMISSION_LEVEL, which is defined in login\loginFunctions.php. False otherwise.
  • [‘server_ip’]: IP address of webserver.
  • [‘client_ip’]: IP address of client server. On local host IP of webserver and client server are equal (127.0.0.1).

3.3.2.2. XFFFFF[GlobStat] masks

Table 3.10 Mask definition for XFFFFF[‘GlobStat’].
Mask name Mask value Position Note
RESIZE_STAT_MASK 0x0000F (1111) 1 All bits of position 1
RESIZE_STAT_MASK_2 0x00003 (0011) 1  
RESIZE_STAT_MASK_TIMECHANGE 0x0000C (1100) 1 Mask for determining the date/time related bits
FPROC_STAT_MASK 0x000F0 2 All bits of position 2
RPROC_STAT_MASK 0x00F00 3 All bits of position 3
UPD_STAT_MASK 0x0F000 4 All bits of position 4
RPROC_UPD_MEDIA_MASK 0xF0000 5 All bits of position 5
ADMIN_LOGIN_MASK
0xF0E0C
F = 1111
E = 1110
C = 1100
  
If the result of masking XFFFFF[GlobStat] with ADMIN_LOGIN_MASK is not zero, then updating is needed which can only be done by someone with administrator rights. As a result, a message box will pop-up giving the end-user the option for logging in as administrator directly.
If the result of the masking is zero, then no message box will pop up. Reason for administrator log in could be:
  • Position 1 (C-mask): LOCATION_DIR_HAS_CHANGED, PUBLIC_DIR_HAS_CHANGED,
  • Position 3 (E-mask): The first bit of position 3 indicates if the file rproc.txt exists or not. As rproc.txt normally exists this bit is ignored when determining whether to propose administrator log on or not. The other 3 bits, however, indicate how to update the file rproc.txt file and this can only be done with administrator rights.
  • Position 5 (F-mask):

3.3.2.3. Use and scope

3.3.3. XFFFFF_Arr object

Instance of the object is initialized in, and returned by CheckProcessStatus_X000FF().

3.3.3.1. Definition

Media status array for each location directory, where the array index is a numerical key. Each array element of XFFFFF_Arr has the following keys (see also Table 3.11):

  • [‘locDirname’]: directory name,
  • [‘XFFFFF’]:
  • [‘dirAccessTime’]: timestamp of directory at the beginning of calling dirThumbs().
  • [‘iminfoAccessTime’]: timestamp of iminfo.xml file at the beginning of calling dirThumbs().
  • [‘resizedAccessTime’]: timestamp of public/private directory at the beginning of calling dirThumbs().

Timestamps are rounded - off of the time returned by the PHP function filemtime(), which returns a UNIX format timestamp (i.e. number of seconds since January 1st, 1970: rounded - off to minutes, and converted back to seconds.

3.3.3.2. Use and scope

  1. The main instance of the object XFFFFF_Arr is initialized in the function CheckProcessStatus_X000FF() and is only used in in function dirThumbs() and functions called inside dirThumbs().
  2. The variable is transferred by means of a JSON object to the update function, initiated by a user with proper permissions, update_media_directories(), implemented in file media-update-progress.php.

3.3.3.3. Example as return value of CheckProcessStatus_X000FF() when phpdefinition.xml exists

Table 3.11 Initialization in CheckProcessStatus_X000FF() when phpdefinition.xml exists.
Array index Assoc.key: locDirname Assoc.key: XFFFFF status Assoc.key: dirAccessTime Assoc.key: iminfoAccessTime Assoc.key: resizedAccessTime
0 DeReis        
1 Weeshuis        
2 HoChiMinh        
3 DaguitHCM-TayNinh        
4 DaguitHCM-Mekong        
5 Mui Ne        
6 Dalat        
7 Nha Trang        
8 Hoian        
9 Hue        
10 Hanoi        
11 Halong Bay        

3.3.4. iminfo object

3.3.4.1. Definition

Content of each iminfo.xml file is stored in PHP SimpleXMLElement object. See also Section 3.1.7.

3.3.5. update_iminfo object

3.3.5.1. Definition

Array with length determined by the number of locations (each location directory has an iminfo.xml file). Each element of the object is 2 bits hexadecimal number, which represents how to update the iminfo.xml in each location directory. Object is initialized in function check_mediacount_iminfo_files().