text:
If you are a subscriber to the JCSM (including members of the AASM), please login to access the journal.
Click here to Subscribe:
$75/volume year for individuals or $140/volume year for institutions to access all current articles and archives published in JCSM.
Click Here to DOWNLOAD the article*:
$20 to access a PDF version of a specific article from the current issue of JCSM.
*Purchase of an electronic download of JCSM provides permission to access and print the issue/article for personal scholarly, research and educational use. Please note: access to the article is from the computer on which the article is purchased ONLY. Purchase of the article does not permit distribution, electronic or otherwise, of the article without the written permission of the AASM. Further, purchase does not permit the posting of article text on an online forum or website.
Subscribers can download and print full articles from current and past issues of the JCSM
Login to JCSM
Join the American Academy of Sleep Medicine and receive a subscription to JCSM with your membership
To determine the relationships between key variables obtained from ambulatory polysomnography (PSG) and the wrist-worn Watch-PAT 200 device in pregnant women.
In this prospective cohort study, women in their third trimester of pregnancy underwent full overnight home PSG using the 22-channel MediPalm system and the Watch-PAT 200 device. PSGs were scored by a blinded, experienced technologist using AASM 2007 criteria; the Watch-PAT was scored automatically by the manufacturer's proprietary software.
A total of 31 pregnant women were studied. Mean age was 30.2 ± 7.1 years; mean gestational age was 33.4 ± 3.0 weeks; mean BMI was 31.9 ± 8.1 kg/m2; 39% of women were nulliparous. Key variables generated by PSG and Watch-PAT correlated well over a wide range, including the apnea-hypopnea index (AHI, r = 0.76, p < 0.001); respiratory disturbance index (RDI, r = 0.68, p < 0.001), mean oxygen saturation (r = 0.94, p < 0.001), and minimum oxygen saturation (r = 0.88, p < 0.001). The area under the curve for AHI ≥ 5 and RDI ≥ 10 were 0.96 and 0.94, respectively. Association between stage 3 sleep on PSG and deep sleep on Watch-PAT was poor. Watch-PAT tended to overscore RDI, particularly as severity increased.
Among pregnant women, Watch-PAT demonstrates excellent sensitivity and specificity for identification of obstructive sleep apnea, defined as AHI ≥ 5 on full PSG. Watch-PAT may overestimate RDI somewhat, especially at high RDI values.
O'Brien LM; Bullough AS; Shelgikar AV; Chames MC; Armitage R; Chervin RD. Validation of Watch-Pat-200 against polysomnography during pregnancy. J Clin Sleep Med 2012;8(3):287-294.
Increasing evidence now shows that sleep disordered breathing (SDB) in pregnancy is associated with adverse outcomes including gestational hypertension1–3 and possibly gestational diabetes.4 During the third trimester of pregnancy, the prevalence of habitual snoring, a characteristic symptom of SDB, is significantly increased compared to that in non-pregnant women and may be as high as 35%.1,5,6 This suggests that approximately one-third of pregnant women may be at risk for SDB, yet most obstetricians do not routinely screen for SDB. Although SDB during pregnancy may often be considered transient and related to the gestational weight gain, the emerging evidence suggesting that SDB may be associated with adverse pregnancy outcomes highlights a need for simple screening devices for SDB in pregnancy.
However, it is not practical logistically to perform polysomnography (PSG) on all pregnant women who screen at high risk for SDB. Overnight PSG studies are labor-intensive, expensive, not always available, and challenging to perform in a timely manner in pregnant women, particularly in late gestation. A simple, home-based device with a low failure rate would facilitate easy recognition and timely intervention for SDB in this population. The Watch-PAT 200 device (Itamar Medical Cesarea, Israel) is a simple, wrist-worn, level 3 device approved for ambulatory diagnosis of SDB.7,8 Measurements are made via finger plethysmography, which is uniquely sensitive to changes in autonomic activity.9,10 Watch-PAT is well validated, including recent validation for sleep staging11–14 and has been used in clinical practice for many years in the non-pregnant population. Such a device has great potential for the diagnosis of SDB in pregnancy; however, its validity in pregnant women has not been previously studied. We compared key variables obtained from simultaneous ambulatory PSG and Watch-PAT 200 in third trimester pregnant women. The third trimester was chosen because SDB risk is likely to peak at this time and therefore has the greatest potential range of disease severity.
Current Knowledge/Study Rationale: Emerging evidence suggests that sleep-disordered breathing (SDB) is prevalent and consequential in pregnancy; however, simple screening devices for SDB have not been validated in this population. We sought to compare key variables from the Watch-PAT 200 with ambulatory polysomnography in 3rd trimester pregnant women.
Study Impact: The Watch-PAT 200 has excellent sensitivity, specificity, and positive and negative predictive values for the identification of SDB in the 3rd trimester of pregnancy. Its use may facilitate rapid screening of pregnant women in addition to making sleep research more feasible in this population.
This study was approved by the Institutional Review Board at the University of Michigan. Women in their last trimester of pregnancy (≥ 28 weeks' gestation) were recruited from obstetric clinics and invited to complete several sleep questionnaires. Those who reported habitual snoring (snoring ≥ 3 nights per week) were classified as at risk for SDB, and those who reported never, rarely, or occasional snoring were classified as non-snorers. An attempt was made to recruit similar numbers of snoring and non-snoring women to undergo an in-home PSG using the MediPalm-20 full PSG system (Braebon, Ontario, Canada) as well as the Watch-PAT 200 device (Itamar, Cesarea, Israel). A research technologist visited the subjects at home in the evening and hooked up the portable PSG and the Watch-PAT. The following morning, the devices were collected and downloaded for analysis.
All subjects underwent home-based digital PSG, including 6-channel electroencephalogram (EEG), electro-oculogram (EOG), submental electromyogram (EMG), leg electromyogram (LEMG), electrocardiogram (ECG), nasal and oral airflow (thermistor, nasal pressure transducer), chest and abdominal respiratory movement (respiratory inductance plethysmography), oxygen saturation, snoring microphone, and body position sensor. For EEG and EOG, the low and high filter settings were set at 0.3 and 35 Hz, respectively; for EMG the settings were 10 and 100 Hz, respectively. The sampling rate was 250 Hz. All of the sleep studies were scored by a single board-certified sleep technician blinded to study group (habitual snorer vs. non-habitual snorer) according to the recent standard criteria of the American Academy of Sleep Medicine.15 Apneas were defined as a drop in peak thermal sensor excursion by > 90% of pre-event baseline, where ≥ 90% of duration met amplitude reduction criteria for apnea, with ≥ 10 sec duration. Obstructive apneas were defined as an apnea with continued respiratory effort, SpO2 desaturation, and/or EEG arousal. Hypopneas were scored if the nasal pressure signal excursion dropped by > 50% of baseline for ≥ 10 sec with either ≥ 3% desaturation or arousal. The apnea-hypopnea index (AHI) comprised the number of apneas and hypopneas per hour of total sleep time; the respiratory disturbance index (RDI) comprised the number of apneas, hypopneas, and respiratory event related arousals (RERAs) per hour of sleep time. Sleep staging and arousals were also scored according to the American Academy of Sleep Medicine (AASM) 2007 rules.16 All studies were reviewed by a board-certified sleep physician (AVS) who was masked to study group.
At the same time as the full PSG, all women also wore the Watch-PAT. Using a peripheral arterial tonometry (PAT) finger plethysmograph and a standard SpO2 probe, the Watch-Pat 200 records the peripheral arterial tonometry (PAT) signal, heart rate, oxyhemoglobin saturation, as well as actigraphy from the inbuilt actigraph. Low and high filter settings for the PAT channel were set at 0.1 and 10 Hz, respectively. Sleep time was estimated using the inbuilt actigraph,17 and sleep was staged using spectral components of the PAT analysis, the details of which have been previously described.12,13 Respiratory events were identified by digital vasoconstriction mediated by α-adrenergic receptors that are exquisitely sensitive to the surges in sympathetic activity that accompany respiratory events. Vasoconstriction results in an attenuated PAT signal, and the Watch-PAT proprietary software algorithm analyzed the PAT signal amplitude along with the heart rate and SpO2 to estimate both the AHI and the RDI. Specifically, respiratory events were scored if one of the following 3 criteria was met: (1) PAT amplitude reduction occurred with acceleration in the pulse rate or increase in wrist activity; (2) PAT amplitude reduction occurred with ≥ 3% oxyhemoglobin desaturation; or (3) ≥ 4% oxyhemoglobin desaturation occurred.18 Manual editing of the automated scoring is possible but was avoided in this study to allow assessment of algorithm performance rather than that of the algorithm plus human operator.
Data were double entered into a database and checked for outliers and normality of the distribution. Analyses were performed using SPSS version 19 (IBM SPSS Statistics). Comparisons between sleep parameters on each device were made using paired t-tests or Wilcoxon signed rank tests, for normally and non-normally distributed continuous data, respectively. McNemar test was used for dichotomous data. Correlations between parameters were performed using Pearson correlation coefficient for normally distributed data and Spearman rho correlation coefficient for non-normally distributed data (AHI and RDI). Bland-Altman Plots were also constructed. These plots provide a graphical means of comparing 2 measures. The differences between measures are plotted against the average of the 2 methods (i.e., average AHI between the PSG and the Watch-PAT). In addition, receiver operator characteristic (ROC) curves were plotted. These curves are graphical representations of the sensitivity (true positive rate) against false positive rate (1-specificity) for the range of obtained AHI and RDI values. Each point on the ROC curve represents a sensitivity/specificity pair, corresponding to a particular decision threshold. The area under the curve (AUC) is a measure of how well a parameter can distinguish between 2 diagnostic groups (e.g., SDB vs. non-SDB). Finally, analysis of the Cohen κ19 statistic was performed to test the classification of the severity of respiratory disturbance as measured by AHI and RDI. All tests were 2-tailed and were considered statistically significant if p < 0.05.
A total of 173 third trimester pregnant women were invited to participate in simultaneous PSG and Watch-PAT monitoring, and 37 (21%) participated. Data from 6 women were excluded because of the technical failure of PSG (n = 3), failure of the Watch-PAT to initialize (n = 1), or < 3 h of sleep on PSG (n = 2) and/or Watch-PAT (n = 1). The latter subject who obtained < 3 h sleep on the Watch-PAT was also one of the 2 women who obtained < 3 h sleep on PSG. The second subject removed the PSG sensors without getting ≥ 3 h of recorded sleep time, but continued to wear the Watch-PAT. As comparative data were not available, this subject was excluded from the analysis. Therefore the number of women included in the final analysis is 31. Table 1 shows the demographic information on study participants.
Demographic information for the 31 study participants
(more ...)
Comparison between mean values of sleep variables between the overnight PSG and the Watch-PAT are shown in Table 2. Among all subjects, 26% had obstructive sleep apnea (AHI > 5). Central apneas were rarely identified by PSG; 77% of women had essentially none, and only 1 subject had a central apnea index > 0.5. In the automatic analysis of the Watch-PAT, central and obstructive apneas are not differentiated. The following parameters measured by PSG showed moderate to good overall correlation with their counterparts measured by Watch-PAT: correlation for TST was r = 0.76, p < 0.001; AHI r = 0.73, p < 0.001; RDI r = 0.68, p < 0.001; mean SpO2 r = 0.94, p < 0.001; and minimum SpO2 r = 0.88, p < 0.001. There were no moderate or strong correlations between sleep stages defined as stages 1 and 2 sleep (light sleep in the Watch-PAT), stage 3 sleep (deep sleep in the Watch-PAT), and REM sleep (light sleep r = 0.10, p = 0.60; deep sleep r = 0.32, p = 0.08; REM sleep r = 0.29, p = 0.12). Figure 1 shows the correlations between key respiratory parameters by group (habitual snorers vs. non-habitual snorers). Correlations were almost equivalent for habitual snorers and non-habitual snorers. Figure 2 shows the correlations between sleep stages by group. Notably, while correlations for the total sample did not reach statistical significance, when analyzed by group non-habitual snorers showed weak correlations between devices for deep sleep and REM sleep (see Figure 2).
Comparison between PSG and Watch-PAT sleep variables (mean ± SD) for 31 subjects
Correlations between sleep time and respiratory measures from simultaneous Watch-PAT and full polysomnography (PSG) among habitually snoring subjects (closed circles and solid lines) and non-habitually snoring subjects (open circles and dashed lines)
Correlations between sleep stages as assessed by simultaneous Watch-PAT and full polysomnography (PSG) among habitually snoring subjects (closed circles and solid lines) and non-habitually snoring subjects (open circles and dashed lines)
Bland Altman plots are shown in Figure 3 and illustrate the mean difference (solid line) and 95% CI (broken line) for total sleep time, AHI, RDI, and sleep stages.
Bland Altman plots showing the mean difference between PSG and Watch-PAT variables (solid line) and the 95% confidence intervals (broken lines) among habitually snoring subjects (closed circles) and non-habitually snoring subjects (open circles)
ROC curves for AHI and RDI are shown in Figures 4A and 4B. The area under the curve for PSG AHI ≥ 5 was 0.96 (95%CI 0.88-1.00). An optimal Watch-PAT threshold of AHI 6.1 provided a sensitivity of 88% and a specificity of 91%. Notably, a sensitivity of 88% and a specificity of 86% occurred at a Watch-PAT AHI threshold of 4.9, almost exactly at the common clinical threshold for significant SDB on full PSG. The sensitivity, specificity, and positive and negative predictive values for the Watch-PAT to identify PSG AHI ≥ 5 were 0.88, 0.87, 0.70, and 0.95, respectively. For an RDI ≥ 10 on PSG, the area under the curve was 0.94 (95%CI 0.86-1.00). An optimal Watch-PAT threshold of 9.3 provided a sensitivity of 100% and a specificity of 82%. The sensitivity, specificity, and positive and negative predictive values for the Watch-PAT to identify a PSG RDI ≥ 10 were: 1.00, 0.81, 0.50, and 1.00, respectively.
Receiver operator characteristic curves for apnea-hypopnea index (A) and respiratory disturbance index (B)
The κ statistic for categorical agreement of AHI ≥ 5 between PSG and Watch-PAT was 0.71 (p < 0.001). The κ statistic for categories of AHI severity (AHI < 1, 1.0-4.9, 5.0-14.9, 15.0-29.9, ≥ 30) between PSG and Watch-PAT was 0.32 (p = 0.002). For RDI ≥ 10 the κ statistic was 0.41 (p = 0.013). However, for categories of RDI severity (RDI < 1, 1.0-4.9, 5.0-14.9, 15.0-29.9, ≥ 30) the κ statistic was not significant (κ statistic 0.08, p = 0.37; Table 3). The Watch-PAT had a tendency to classify apnea severity as slightly worse than that reflected on the PSG, especially for RDI measurement. For example, there were 18 subjects measured by PSG to have an RDI in the range of 1.0-4.9, but the Watch-PAT classified only 5 in this range, with 12 in the range of 5.0-14.9 and 1 classified in the RDI range 15.0-29.9. Of note, with the exception of the latter subject, most subjects whose RDI was classified too high had RDIs close to the lower boundary of the mild range (generally RDI < 8).
Concordance between PSG and Watch-PAT for severity of AHI and RDI
Approaches that allow effective identification of SDB among pregnant women are urgently needed, given that accumulating evidence suggests independent associations between SDB and maternal morbidity, if not adverse fetal outcomes as well.1–5,20,21 Our findings now demonstrate for the first time that the Watch-PAT 200 ambulatory device has excellent sensitivity and specificity, as well as positive and negative predictive values, for detection of AHI ≥ 5 on full PSG in third trimester pregnant women. This is in agreement with earlier studies using PAT technology in the non-pregnant population.7–9,22 When using RDI criteria, the Watch-PAT had good sensitivity and specificity but appeared to be more sensitive than PSG to subtle physiological changes. This resulted in a relatively weak positive predictive value but an excellent negative predictive value when using RDI ≥ 10 as the threshold. The Watch-PAT 200 demonstrated good correlation with ambulatory PSG for key respiratory variables such as AHI, RDI, mean SpO2, and nadir SpO2, with better correlations found in snoring women. Relationships between sleep stage characteristics by these devices were poor in this cohort.
Previous studies have demonstrated that pregnancy is associated with an increased risk for SDB that may play a role in gestational hypertension and preeclampsia.1–3,6 The increasing awareness of SDB risk in pregnancy is evidenced by the recent surge in published literature in this field and highlights a currently unmet need. Evaluation for SDB during pregnancy must be prioritized. However, perhaps due to the logistical difficulty and the constrained time frame for PSG in pregnant women, these subjects often are not referred to sleep laboratories. Even the use of full ambulatory PSG at home can be difficult in pregnancy: women are often uncomfortable, particularly in later gestation, and belt placement for respiratory effort can be challenging. Effective diagnostic alternatives that are easy to use with less dependence on skilled technologists could increase both availability of testing and willingness of pregnant women to undergo it.
Considerable effort is expended to develop simple SDB monitoring for use in the home environment. Although many devices correlate well with in-laboratory PSG, the failure rate of portable systems is typically high, necessitating repeat studies. Several previous studies have reported on objective measures of sleep during pregnancy. Such measures have included full in-laboratory PSG23,24 (including esophageal pressure monitoring25), various portable PSG devices,26–29 and the Watch-PAT.30 However, none of these studies were designed to validate the devices or methods among pregnant women. Furthermore, the threshold for the presence of disease was not the same across studies, in part due to use of different methodologies to identify SDB; such approaches have included flow limitation,27,29 autonomic activation,30 limited channel cardiorespiratory monitors,28 and AASM recommended channels.23,24
The Watch-PAT has been well validated in the non-pregnant population,7,8,10,18,31,32 is FDA-approved for home testing, and is reimbursable through most insurance carriers. Our findings validate key respiratory measures generated by the Watch-PAT 200 in third trimester pregnant women. However, the overall agreement between PSG and Watch-PAT in categorization of SDB severity into levels more refined than present vs. absent was only moderate. For AHI, and particularly for RDI, the Watch-PAT in comparison to PSG appeared to overestimate severity at higher ranges. This disagreement could arise for a number of reasons. First, the use of changes in autonomic activity to detect respiratory events and arousals is likely to be more sensitive to subcortical activation that would not be scored on traditional PSG.33 Second, pregnancy is associated with hemodynamic changes, notably increased blood volume. This may be important in increasing sympathetic activity, particularly in hypertensive pregnancies.34,35
Furthermore, this study validated the Watch-PAT against portable PSG, which may also differ slightly from in-lab PSG. The discrepancy between Watch-PAT performance in identification of SDB (present vs. absent) and categorization into severity levels may be partially explained by the fact that changes in categorical classification can result from only small changes in AHI or RDI. Given the differences in device performance, additional research seems warranted to compare the clinical predictive value of the Watch-PAT and full PSG in pregnant women. Autonomic activation, with or without cortical activation, may prove to be a better physiological marker of overnight sympathetic activity. Several studies have shown that increased sympathetic activity is associated with higher risk of cardiovascular mortality.36 Therefore, Watch-PAT categorizations of SDB severity could prove more useful than those provided by standard PSG.
Aside from accuracy, an apparent strength of the Watch-PAT approach is that it has a low rejection rate (only once did it fail to initialize in this study). Low rejection rates have been found in other studies with Watch-PAT,7 unlike unattended PSG where the rejection rate is typically much higher,37,38 up to one-third of studies performed.37 In this study, three women had technical failure of PSG, compared to only 1 woman with Watch-PAT. Patients also prefer home-based studies to attended studies.39 Pregnant women often have other young children at home, and in addition do not look forward to the discomfort of a night in a sleep laboratory. To date, only one previous study has applied PAT technology in pregnant women.30 This study recruited 17 women with preeclampsia and 25 matched controls with uncomplicated pregnancies and used both the Watch-PAT 100 (an earlier version of the Watch-PAT 200) and Endo-PAT, a device to measure endothelial function. The authors found that women with preeclampsia had a significantly higher RDI and a lower endothelial function index than controls. Furthermore, blood pressure correlated with RDI and an endothelial function index. These data augment an emerging literature that links SDB and hypertensive diseases of pregnancy.1,3,20,40
Mean proportions of light sleep, deep sleep, and REM sleep as measured by the two devices were similar, but absolute correlations were poor. Bland Altman plots showed agreement between Watch-PAT and PSG for light sleep and REM sleep, although agreement for deep sleep was not good. The Watch-PAT tended to underscore deep sleep at lower proportions and overscore it at higher proportions. The PAT technology has only recently been used to stage sleep,12–14 and similar data have not been reported in pregnant women. Pregnant women are known to sleep poorly, but this would not fully explain the discrepancies in sleep staging observed here, as adults with SDB (among whom the algorithms have been validated) also sleep poorly.
There are several limitations to this study. We did not validate Watch-PAT against attended PSG. This was in part due to the logistical difficulty of scheduling third trimester pregnant women to spend a night in the laboratory. Women were recruited whether they reported habitual snoring or not, and this sample is not necessarily representative of pregnant women who may be referred to sleep clinics for evaluation. This aspect of our design, however, is also a strength, in that data are likely representative of third trimester pregnant women more generally. Finally, only women in the third trimester were studied, and our results may not apply to the first and second trimesters. However, validity of the Watch-PAT during the third trimester, when some physiologic changes from baseline may be most extreme, suggests that changes earlier in pregnancy are unlikely to significantly diminish Watch-PAT performance below that previously reported for non-pregnant women and currently observed in the third trimester.
In summary, the Watch-PAT 200 has excellent sensitivity, specificity, and positive and negative predictive values for identification of pregnant women with SDB (defined as AHI ≥ 5). Coupled with a low failure rate and ease of use, particularly for pregnant women, the performance of the Watch-PAT suggests it could be used to facilitate simple and rapid screens of pregnant women, reduce the waiting time for diagnosis, and enable treatment within the short time frame necessary to have the highest chance of positive impact on maternal and fetal outcomes of pregnancy. Our data also suggest that the Watch-PAT could make research on SDB in pregnancy much more feasible, perhaps in larger samples of women for whom research based on full PSG would be inaccessible, undesirable, intolerable, or financially prohibitive.
This was not an industry supported study. MediPalm devices were provided through an educational gift by Braebon Medical Corporation to Dr. Armitage. Dr. O'Brien receives equipment support from Philips Respironics Inc., Dr. Armitage is a Consultant for Eisai Inc., and Dr. Chervin has received educational grants from Philips Respironics Inc., Fisher Paykel Inc., and is named in patents owned by the University of Michigan for signal analysis diagnostic algorithms and hardware relevant to the assessment and treatment of sleep disorders. The other authors have indicated no financial conflicts of interest.
The authors thank the pregnant women who participated in this study and allowed us into their homes. We are indebted to research assistants Meghan M. Hewlett, B.A.; Fatema Arastu, B.A.; and Kristine Martel, Ph.D. And to research coordinator Lori A. Kempf, B.A., C.C.R.P., for dedicated assistance with subject recruitment and data collection. Thanks also to Robert Hagbloom, R.P.S.G.T., who scored all of the PSG studies. Financial support for this study provided by The Gene and Tubie Gilmore Fund for Sleep Research, and the National Institutes of Health (R21HL089918 and K23HL095739 to Dr. O'Brien). Dr. O'Brien is also supported in part by R21HL087819. MediPalm devices were provided through an educational gift by Braebon Medical Corporation to Dr. Armitage.
Franklin KA, Holmgren PA, Jonsson F, Poromaa N, Stenlund H, Svanborg E, authors. Snoring, pregnancy-induced hypertension, and growth retardation of the fetus. Chest. 2000;117:137–41. [PubMed]
Perez-Chada D, Videla AJ, O'Flaherty ME, et al., authors. Snoring, witnessed sleep apnoeas and pregnancy-induced hypertension. Acta Obstet Gynecol Scand. 2007;86:788–92. [PubMed]
Bourjeily G, Raker CA, Chalhoub M, Miller MA, authors. Pregnancy and fetal outcomes of symptoms of sleep-disordered breathing. Eur Respir J. 2010;36:849–55. [PubMed]
Facco FL, Grobman WA, Kramer J, Ho KH, Zee PC, authors. Self-reported short sleep duration and frequent snoring in pregnancy: impact on glucose metabolism. Am J Obstet Gynecol. 2010;203:142e1-5. [PubMed Central][PubMed]
Loube DI, Poceta JS, Morales MC, Peacock MD, Mitler MM, authors. Self-reported snoring in pregnancy. Association with fetal outcome. Chest. 1996;109:885–9. [PubMed]
Izci B, Vennelle M, Liston WA, Dundas KC, Calder AA, Douglas NJ, authors. Sleep-disordered breathing and upper airway size in pregnancy and post-partum. Eur Respir J. 2006;27:321–7. [PubMed]
Bar A, Pillar G, Dvir I, Sheffy J, Schnall RP, Lavie P, authors. Evaluation of a portable device based on peripheral arterial tone for unattended home sleep studies. Chest. 2003;123:695–703. [PubMed]
Choi JH, Kim EJ, Kim YS, et al., authors. Validation study of portable device for the diagnosis of obstructive sleep apnea according to the new AASM scoring criteria: Watch-PAT 100. Acta Otolaryngol. 2010;130:838–43. [PubMed]
Schnall RP, Shlitner A, Sheffy J, Kedar R, Lavie P, authors. Periodic, profound peripheral vasoconstriction--a new marker of obstructive sleep apnea. Sleep. 1999;22:939–46. [PubMed]
Grote L, Zou D, Kraiczi H, Hedner J, authors. Finger plethysmography--a method for monitoring finger blood flow during sleep disordered breathing. Respir Physiol Neurobiol. 2003;136:141–52. [PubMed]
Lavie P, Schnall RP, Sheffy J, Shlitner A, authors. Peripheral vasoconstriction during REM sleep detected by a new plethysmographic method. Nat Med. 2000;6:606[PubMed]
Bresler M, Sheffy K, Pillar G, Preiszler M, Herscovici S, authors. Differentiating between light and deep sleep stages using an ambulatory device based on peripheral arterial tonometry. Physiol Meas. 2008;29:571–84. [PubMed]
Herscovici S, Pe'er A, Papyan S, Lavie P, authors. Detecting REM sleep from the finger: an automatic REM sleep algorithm based on peripheral arterial tone (PAT) and actigraphy. Physiol Meas. 2007;28:129–40. [PubMed]
Hedner J, White DP, Malhotra A, et al., authors. Sleep staging based on autonomic signals: a multi-center validation study. J Clin Sleep Med. 2011;7:301–6. [PubMed Central][PubMed]
Iber C, Ancoli-Israel S, Chesson A, Quan S, authors. AASM manual for the scoring of sleep and associated events: rules, terminology and technical specifications. 2007. Westchester, IL: American Academy of Sleep Medicine;
Silber MH, Ancoli-Israel S, Bonnet MH, et al., authors. The visual scoring of sleep in adults. J Clin Sleep Med. 2007;3:121–31. [PubMed]
Hedner J, Pillar G, Pittman SD, Zou D, Grote L, White DP, authors. A novel adaptive wrist actigraphy algorithm for sleep-wake assessment in sleep apnea patients. Sleep. 2004;27:1560–6. [PubMed]
Pittman SD, Ayas NT, MacDonald MM, Malhotra A, Fogel RB, White DP, authors. Using a wrist-worn device based on peripheral arterial tonometry to diagnose obstructive sleep apnea: in-laboratory and ambulatory validation. Sleep. 2004;27:923–33. [PubMed]
Cohen J, author. A coefficient of agreement for nominal scales. Educ Psychol Meas. 1960;20:37–46
Louis JM, Auckley D, Sokol RJ, Mercer BM, authors. Maternal and neonatal morbidities associated with obstructive sleep apnea complicating pregnancy. Am J Obstet Gynecol. 2010;202:261e1-5. [PubMed]
Tauman R, Many A, Deutsch V, et al., authors. Maternal snoring during pregnancy is associated with enhanced fetal erythropoiesis--a preliminary study. Sleep Med. 2011;12:518–22. [PubMed]
Pittman SD, MacDonald MM, Fogel RB, et al., authors. Assessment of automated scoring of polysomnographic recordings in a population with suspected sleep-disordered breathing. Sleep. 2004;27:1394–403. [PubMed]
Maasilta P, Bachour A, Teramo K, Polo O, Laitinen LA, authors. Sleep-related disordered breathing during pregnancy in obese women. Chest. 2001;120:1448–54. [PubMed]
Prodromakis E, Trakada G, Tsapanos V, Spiropoulos K, authors. Arterial oxygen tension during sleep in the third trimester of pregnancy. Acta Obstet Gynecol Scand. 2004;83:159–64. [PubMed]
Guilleminault C, Kreutzer M, Chang JL, authors. Pregnancy, sleep disordered breathing and treatment with nasal continuous positive airway pressure. Sleep Med. 2004;5:43–51. [PubMed]
Guilleminault C, Querra-Salva M, Chowdhuri S, Poyares D, authors. Normal pregnancy, daytime sleeping, snoring and blood pressure. Sleep Med. 2000;1:289–97. [PubMed]
Edwards N, Blyton CM, Kesby GJ, Wilcox I, Sullivan CE, authors. Pre-eclampsia is associated with marked alterations in sleep architecture. Sleep. 2000;23:619–25. [PubMed]
Olivarez SA, Maheshwari B, McCarthy M, et al., authors. Prospective trial on obstructive sleep apnea in pregnancy and fetal heart rate monitoring. Am J Obstet Gynecol. 2010;202:552e1-7. [PubMed]
Connolly G, Razak AR, Hayanga A, Russell A, McKenna P, McNicholas WT, authors. Inspiratory flow limitation during sleep in pre-eclampsia: comparison with normal pregnant and nonpregnant women. Eur Respir J. 2001;18:672–6. [PubMed]
Yinon D, Lowenstein L, Suraya S, et al., authors. Pre-eclampsia is associated with sleep-disordered breathing and endothelial dysfunction. Eur Respir J. 2006;27:328–33. [PubMed]
Pillar G, Bar A, Betito M, et al., authors. An automatic ambulatory device for detection of AASM defined arousals from sleep: the WP100. Sleep Med. 2003;4:207–12. [PubMed]
Penzel T, Kesper K, Ploch T, Becker HF, Vogelmeier C, authors. Ambulatory recording of sleep apnea using peripheral arterial tonometry. Conf Proc IEEE Eng Med Biol Soc. 2004;5:3856–9. [PubMed]
Sforza E, Jouny C, Ibanez V, authors. Cardiac activation during arousal in humans: further evidence for hierarchy in the arousal response. Clin Neurophysiol. 2000;111:1611–9. [PubMed]
Yang CC, Chao TC, Kuo TB, Yin CS, Chen HI, authors. Preeclamptic pregnancy is associated with increased sympathetic and decreased parasympathetic control of HR. Am J Physiol Heart Circ Physiol. 2000;278:H1269–73. [PubMed]
Greenwood JP, Scott EM, Stoker JB, Walker JJ, Mary DA, authors. Sympathetic neural mechanisms in normal and hypertensive pregnancy in humans. Circulation. 2001;104:2200–4. [PubMed]
Thayer JF, Yamamoto SS, Brosschot JF, authors. The relationship of autonomic imbalance, heart rate variability and cardiovascular disease risk factors. Int J Cardiol. 2010;141:122–31. [PubMed]
Portier F, Portmann A, Czernichow P, et al., authors. Evaluation of home versus laboratory polysomnography in the diagnosis of sleep apnea syndrome. Am J Respir Crit Care Med. 2000;162(3 Pt 1):814–8. [PubMed]
Dingli K, Coleman EL, Vennelle M, et al., authors. Evaluation of a portable device for diagnosing the sleep apnoea/hypopnoea syndrome. Eur Respir J. 2003;21:253–9. [PubMed]
Lloberes P, Sampol G, Levy G, et al., authors. Influence of setting on unattended respiratory monitoring in the sleep apnoea/hypopnoea syndrome. Eur Respir J. 2001;18:530–4. [PubMed]
Izci B, Riha RL, Martin SE, et al., authors. The upper airway in pregnancy and pre-eclampsia. Am J Respir Crit Care Med. 2003;167:137–40. [PubMed]


text:
Have the last word on annual dictionary update
PEACHCOT, yarn bombing, fiscal cliff, c***-block, jorts, diabesity, dilligaf, frape, mummy porn...which is your word of 2012?
Yep, those busy bees at the Macquarie Dictionary lab have had their ears to the ground all year, once again collecting all the new words that have gripped the nation, entered the vernacular and impacted our lives, to choose a Word of the Year in the annual update of the Macquarie Dictionary Online.
The categories have been selected, the nominations are in, and voting opened on Monday for what we Aussies think is the most striking contribution to Australian English in 2012.
The voting will determine the People's Choice.
The overall winning word will be selected by the Macquarie Dictionary Word of the Year committee, chaired by the Vice-Chancellor of Sydney University.
Gympie State High English head of department Emma Palm said yesterday the English language was constantly evolving and that was not necessarily a bad thing.
"Language is not static," she said.
"Taste and fashion influence our usage, which means some words are rarely written or spoken. Our access to international media has also influenced the words we choose; for instance, very few people use drongo or dingbat as put-downs now.
"My favourites this year are: technomite, peachcot, silo mentality, phantom vibration syndrome, second screener, jorts, diabesity, passive drinking, self-quantifying and Sputnik moment.
"Politically, I'm disturbed about the dehumanising effect of using terms such as enterprise migration agreement, IMA and green-on-blue, when it's people we're talking about, not just numbers."
The overall winning word will be announced on February 6.
Vote for your favourite on the Macquarie Dictionary website.
First World problem
A problem that relates to the affluent lifestyle of the First World such as having to settle for plunger coffee when one's espresso machine won't work
A Maori who has left NZ to live in Australia
Acronym for Do I Look Like I Give a F***?
Phantom Vibration Syndrome
Constant anxiety in relation to one's mobile phone and an obsessional conviction that the phone has vibrated in response to an incoming call

subset: commoncrawl


text:
Unless they specialize in a certain, ahem, type of film work, most actors dread shooting sex scenes. But in the mesmerizing "Chloe," Amanda Seyfried had more difficult task -- shooting an explicit scene with an iconic female actress (Julianne Moore) and with a demanding director.
"I was counting down the days until we had to shoot that," Seyfried said of the movie which opens Friday.
Director Atom Egoyan knew exactly where he wanted to go with the scene to convey the proper mood in a movie dealing with obsession, even giving Seyfried and Moore a demonstration with (clothed) stand-ins. "He brought the stand-ins into the bedroom of the hotel where we were shooting and had them…kind…of perform in the way we were supposed to," says Seyfried. "Atom was like, 'Do you understand that?' He was trying to make it very clear what he wanted."
Moore and Seyfried insisted on one change to that scene -- "to make it gentler," said Seyfried, and "we won the day."
Then they were ready, even if the awkward part lay ahead. "When it got to that day (Julianne and I) were both like, 'Okay!' " laughed Seyfried. "We know what we have to do technically and now we just have to take our pants off and hop into bed."
The scene was basically one intricate movement shot seven times with one camera. She calls the end result "powerful."
"It was good, a nice team effort," says Seyfried of her co-star. "But it was awkward. Because that's what it is -- awkward. Intimate scenes are awkward."


text:
The American Society of Landscape Architects (ASLA) has announced the call for presentations for the 2013 Annual Meeting and EXPO in Boston. The 2013 event will take place November 15 – 18 at the Boston Convention and Exposition Center.
More than 6,000 attendees are expected, and the meeting will feature a diverse spectrum of industry experts speaking on a wide range of subjects, from sustainable design to active living to best practices and new technologies.
More than 130 education sessions and field sessions will be presented during the meeting, providing attendees with the opportunity to earn up to 21 professional development hours under the Landscape Architecture Continuing Education System (LA CES). Many of the sessions will also qualify for continuing education credit with the Green Building Certification Institute (toward LEED AP credential maintenance), the American Institute of Architects, the American Institute of Certified Planners, and other allied professional organizations and state registration boards.
Submit your proposals now. The deadline for education session proposals is February 6, 2013.
Image credit: ASLA


text:
A Buxton teenager will be facing the challenge of his life in September when he attempts to scale Africa's highest peak.
Ryan Paisley will be climbing Kilimanjaro in Tanzania with three friends to raise funds for the Meningitis Research Foundation.
The 19-year-old was inspired to conquer the nearly 6,000-metre ascent for the charity after he saw a presentation on the disease at university in Loughborough.
Ryan, of Burbage, said: "It made me realise how serious it is, especially to babies, toddlers and young adults of which it mostly affects. I also have a friend who had a bad scare with meningitis."
The first year sport and exercise science student has already raised £1,000 of his £2,025 target and has been donating his wages from his job at Ferodo in Chapel-en-le-Frith, where he works in the holidays.
"I have done bronze, silver and gold Duke of Edinburgh expeditions and took part in a few outdoor activity trips throughout school, but nothing compared to this magnitude, so this will be a challenge," he added.
"I am currently just keeping myself generally fit, playing sport at university and at home when I am back on breaks. However I will have to take part in altitude training prior to my climb. The majority of people who climb Kili do experience altitude sickness."
The expedition is expected to take five to six days.
To make a donation, visit Ryan's sponsorship page at virginmoneygiving.com.


text:
Adobe's free web-based free version of Adobe Photoshop is now available as a beta. Photoshop Express allows users to store up to 2GB of images, make edits to their photos, and share them, all online.
First rumoured last year, Photoshop Express is a way for Adobe to compete with free applications like Google's Picasa, which have emerged over the last few years.
Since it's to be used by consumers, the company has put a lot of effort into ease-of-use. In a few clicks, users will be able to make standard edits, such as removing blemishes and red-eye, converting to black and white, cropping and resizing. No experience is required, Adobe said.
Users will also be able to integrate with social-networking sites such as Facebook.
Photoshop Express works with all major browsers, including Firefox, Internet Explorer and Safari, Adobe said. It requires an internet connection and Flash Player 9 to work.
The tool is based on Flex, Adobes cross-browser plug-in technology for multimedia.
At first, Photoshop Express is available only to US residents and only in English. Users may experience slow performance if accessed outside of the US, Adobe warned. Future plans include availability in other languages and countries.
This isn't Adobe's first foray into web-based services. Adobe announced the availability of Premiere Express, an online video editing available on partner sites such as MTV and Photobucket, early last year.


text:
User:Kevin Reid
From Erights
Revision as of 13:57, 6 May 2010 by Kevin Reid (Talk | contribs)
My posts on the e-lang mailing list.
Roughly in order of liveness.
- I am currently the semi-official E-on-Java maintainer as Mark Miller is busy with other projects.
- Caja-CapTP — adapting CapTP to Caja.
- E-on-CL — E implementation
- eel/runebot/murepl, the IRC bot etc. project (source not released; currently runs on my personal laptop which is a situation that Really Ought To Be Fixed)
- E-on-Haskell — E implementation
- kEIO — EIO implementation for E-on-Java
- Den — distributed virtual world platform
- The surprise list.
- gendoc.e
- /java3d.e-awt — Java 3D API used from E
- /scribble.e-awt — Simple Swing UI application with custom graphics
- /User far proxy — project to allow a human to provide the behavior of a far ref
This should probably be migrated into an issue tracker. Right now we're nominally using SourceForge, but I, at least, find it tedious to work with.
That said, these are my personal things-which-ought-to-be-done, and not the reflection of any consensus; I'm just dumping them here because it's better than them living in a random file on my hard disk.
E-on-Java work to do
- Change the default taming policy for no-safej-file classes from ALL to NONE. (2010-02-27)
- Add shortcut syntax to SafeJ files for declaring allow-all, then replace the functionality of ApprovedClassList with safej files using that syntax. (2010-02-27)
- Documentation, including impl-specific, should go to the wiki. Spec tests go to the wiki (Category:E specification). Impl-specific (features and regression) tests stay in source tree. (2010-02-27)
E-on-CL work to do/misc notes
- Old notes from Jul 17 2008:
- eocl r992:993 introduced a slowdown [in executing --updoc tests/captp/introducer.updoc].
- Stuff about custom method specializers in SBCL: [1] [2] [3]
- transparent does NOT imply ok-for-Selfless. transparent can be mutable, e.g. FlexList (w/o value guard?) is transparent. TODO: revise Selfless to drop the independent Selfless auditor, in favor of TransparentSelfless approval, etc. -- because (Selfless+Transparent) isn't sufficient, we need to require immutability as well
- invocation for benchmarking + sprof-tree:
time rlwrap ./clrune -L--eval -L'(require :sb-sprof)' -L--load -L ~/Documents/sbslow-project/sbcl/sprof-tree.lisp -L--eval -L'(setf sb-sprof:*sample-interval* 0.1)' -L--eval -L'(defun sb-sprof::report () (with-open-file (s "sampler-updoc.trace" :direction :output :element-type :default :if-exists :supersede) (sb-sprof::write-sampler-data s)))' -p ../sb-parse-cache.sexp --updoc --profile sb-sprof tests/captp/AnswersTable.updoc
- this may be obsolete due to having profile options in clrune —Kevin Reid 08:56, 6 May 2010 (CDT)
E design work
- Idea: Every directory serves as a root (that is, has the facilities of <file> like optUnget). This allows chrooting and allows updoc tests to be given virtual roots that aren't different in implementation from the real root.(2010-02-27)
- File pathname getting is tamed away, use <myRoot>.optUnget instead. The REPL's printFunc's textWriter has authority to show paths.
- Post as unresolved design issue whether to use E-on-CL's isQuoting and printSame methods in standard E. (2010-02-27)
- Post the contents of my 'To be discussed with MarkM' file on the wiki. (2010-02-27)


text:
PCoIP Log Viewer update for View 6.0
Let me open this post with an apology – I have been pulled away from supporting the Log Viewer (and the Config Utility) for far too long and correspondingly this site has suffered as well. So for all the users of these tools – I apologize. I plan to devote time to both sets of tools in the coming weeks. Thank you for hanging in there and finding value in these tools despite the absence.
Ok, with that out of the way-
What's New
View 6.0 is here and with it – you guessed it – changes to the log file format. In a previous post (here) I detailed a significant change to the log parser with the intent of making future parser updates much easier. I am happy to say that investment is paying off. Minor changes were required to support both View 5.3 and View 6.0. Previously, weaving in the new data detection and extraction would have required significantly more effort and would have been much more fragile. As it is, things are working almost exactly as designed (I did make a few framework tweaks mostly around package visibility but I should have made those in the first place, so this was more of a correction than new development).
That being said, looking through the new files I am seeing a lot of information that is being reported differently, old information that was previously gone but is now back, existing data that is no longer there, and some data that is entirely new. Some of this new data might turn out to be of great value. I'll get into some of those differences in a moment, but it's these discoveries that lead me to believe I'll have at least one more follow-up release for View 6.0 once I confirm the value of this new data.
Reaching the Plateau – or Not
One change you will notice is that Plateau no longer seems to be tracked:
View 5.3 log file:
Tx thread info: bw limit = 1276, plateau = 1152.0, avg tx = 5.3, avg rx = 4.6 (KBytes/s)
View 6.0 log file:
Tx thread info: bw limit = 150, avg tx = 27.0, avg rx = 7.5 (KBytes/s)
So, to maintain simplicity, I am just setting Plateau to '0' in the graphs. From what I can tell, the value didn't move as has happened in previous releases, it's just not in there any longer. If I hear about or find some way to derive it I'll add it back in. Plateau was a good indicator of how much bandwidth PCoIP "thought" it could use at any given time so I do think some value has been lost here.
Other Changes
Loss conditions seem to have a completely new logging format with some new data not found in previous logs:
06/20/2014, 09:33:20.028> LVL:3 RC: 0 MGMT_PCOIP_DATA :ubs-BW-loss: -----> lost=1 06/20/2014, 09:33:20.047> LVL:3 RC: 0 MGMT_PCOIP_DATA :ubs-BW-tcp1: -----> lost/xmit=0.20/85.47, rate=0.2391 06/20/2014, 09:33:20.047> LVL:3 RC: 0 MGMT_PCOIP_DATA :ubs-BW-tcp2: -----> active[kbit/s]=12338.8543, TCP fair bw[kbit/s]=3317.7040, MSS=1100.00, RTT(aged)=124.1, loss=0.0391 06/20/2014, 09:33:20.047> LVL:1 RC: 0 MGMT_PCOIP_DATA :ubs-BW-decr: Decrease (loss) loss=0.001 current[kbit/s]=5819.2823, active[kbit/s]=12338.8543 -> 5734.3661, adjust factor=1.46%, floor[kbit/s]=104.0000
Tracing to the endpoint is also something I came across. It might be fun to build a network map out of this if the data is valid and usable. (IPs changed to protect the guilty):
06/20/2014, 09:24:58.026> LVL:2 RC: 0 SOCK_UTIL :trace_route: ----> trace complete. 30 hops detected 06/20/2014, 09:24:58.026> LVL:2 RC: 0 SOCK_UTIL :hop [ 1] -- rtt [1]: 2 ms, [2]: <1 ms, [3]: <1 ms -- ip: 18.104.22.168 -- name: view.somehost.com 06/20/2014, 09:24:58.026> LVL:2 RC: 0 SOCK_UTIL :hop [ 2] -- rtt [1]: 2 ms, [2]: 1 ms, [3]: 2 ms -- ip: 220.127.116.11 -- name: 22.214.171.124 06/20/2014, 09:24:58.026> LVL:2 RC: 0 SOCK_UTIL :hop [ 3] -- rtt [1]: 2 ms, [2]: 2 ms, [3]: 1 ms -- ip: 184.108.40.206 -- name: 22.214.171.124 06/20/2014, 09:24:58.026> LVL:2 RC: 0 SOCK_UTIL :hop [ 4] -- rtt [1]: 34 ms, [2]: 37 ms, [3]: 35 ms -- ip: 126.96.36.199 -- name: 188.8.131.52
And lastly some new image stats that look VERY interesting:
06/19/2014, 12:09:01.723> LVL:2 RC: 0 MGMT_IMG :Image stats [MBits/s]: Total=0.428667 Lossy=0.120958 Lossless=0.242432 Build=0.0652768 (Lossy 0.0652768) Cache=0.000947985 06/19/2014, 12:09:01.723> LVL:2 RC: 0 MGMT_IMG :Image stats [MPPS]: Lossy=0.195575 Txt=0.162369 Bkgnd=0 Motion=0 TileCache=0.00347088 - deprecated - values duplicated below 06/19/2014, 12:09:01.723> LVL:2 RC: 0 MGMT_IMG :Image stats [MPPS]: Changed=0 LS(txt+bkg)=0.162369 LY(chg)=0.195876 LY(bld)=0.297299 LY(LS_res)=0 06/19/2014, 12:09:01.723> LVL:2 RC: 0 MGMT_IMG :Image stats [MPPS]: Motion=0 zero_offset_tile_cache_hits=0.00347088 offset_tile_cache_hits=0 temporal_cache_hits=0 06/19/2014, 12:09:01.723> LVL:2 RC: 0 MGMT_IMG :Image stats [MPPS]: LY_mec_restart=0 LY_txt_restart=0
First, it looks as if some previous stats like build/delta/lossy/changed have returned after getting lost somewhere around the 5.x time frame. Before I throw those back in, I need to validate them a bit more. But more importantly, I believe this to be the first real appearance of CACHE stats in the logs! That might be very interesting! I have put in some requests to Teradici to help make sure I can interpret these values correctly and once I have that confirmed I suspect I'll need to add a few new graphs in.
Getting the Update
If you already have the Log Viewer installed, you should get the update on the next launch. For those who do not have it, you will need to have Java 1.6+ installed and you can find the JNLP file here: http://hirstius.com/webstart/pcoip/PCoIPLogViewer.jnlp
As always, I expect there to be bugs. I also have not validated the parser against EVERY possible build of View 6.0 though I did try to cover what I believe is the beta and the GA release. If you see an error saying no valid parser can be found, please reach out in the comments and I'll arrange some way for you to send me the file so I can figure out what went wrong. Same thing for other errors I just don't have a large sampling of data files to test against right now but I wanted to get this initial update out quick in the hopes that it helps at least some people right off the bat.
In closing, I want to say thank you again for your patience and I hope you continue to find this tool useful.
Dynamic PCoIP in View 5.3
Dropping in a quick update from VMWorld Europe…
If you read my previous post you know that a new feature was added to View 5.2 that was stated as something along the lines of "GPO options take effect immediately for PCoIP". Well, it was true but it didn't exactly work as intended. It worked only with a very small number of options and hence was rendered not terribly useful.
I am happy to say that I have been working with near-release ready code for View 5.3 and this feature now seems to work as intended for pretty much all of the important tuning options. This is great news! It means I have to go back and dust off my work on the real-time tuner tool I had began building at the start of the year and combine it with some updates to the PCoIP Configuration Utility, but I believe I can deliver a really solid workflow for the creation, distribution, and (dynamic) application of PCoIP tuning profiles.
Stay tuned in the coming weeks and I'll keep you updated as to how things progress.
PCoIP Log Viewer Updated for View 5.2
First off, an apology. This update took way too long to get into your hands, but here it is… In this post, I'll explain the new update, and then likely dive into far more detail than anyone ever wanted to know about the new parsing framework included in this release.
Update for View 5.2
Goodbye standalone parser
With this release the PCoIP Log Viewer now supports parsing View 5.2 logs. There's a pretty major change in how this functionality is provided – View 5.2 log files should only be parsed directly from the Viewer. Let me repeat that – the standalone parser will not work for 5.2 log files, you now parse these directly in the Viewer. For any log files prior to View 5.2 you will still need to use the standalone parser. I realize this is likely to cause some confusion and frustration, but I had to make a break from the "legacy" parser if I was going to maintain my sanity. It also sets the stage for some future development I hope to do, and which I'll talk more about later. This also means, for the moment, if you depend upon embedding the parser into your VDI images to pre-process the log files before opening them in the Viewer (and I know some people have scripted this) that you are out of luck. There's two ways to look at this – I am the Dark Lord Satan out, specifically, to ruin your life, or, your scripting is now simplified in that you no longer need to pre-process the files or add an executable to the master image/clones. Keep the logic that moves the log files out, and then just open THOSE in the Log Viewer. However, if I get enough hatred and anger, I am certainly open into looking at making a new standalone parser based off the new framework. The catch with that is that it may require Java as a pre-req, or need to be wrapped into a much larger executable, so it's not a perfect replacement.
Opening View 5.2 log files
With the log file parser now integrated into the Viewer itself, using the new View 5.2 support is as easy as dragging and dropping a "raw" logfile into the Viewer window, or opening the file via the Open Log file menu option. Just to be clear by "raw" logfile, I mean the 'pcoip_server_<year>_<month>_<day>_<id>.txt (pcoip_server_2013_05_17_00000b90.txt) file. You can still open regular XML files from the standalone parser the same way you always have. Once opened things should look and work more or less as they always have, no new changes to learn there. Here's a video of the basic usage (except you now CAN open files from the file dialog, and the parser warning is gone):
Getting the Update
All you should need to do is launch the PCoIP Log Viewer while connected to the internet and it should auto-update. If you don't have the Log Viewer installed already you'll need Java 6.x or greater installed, then you can go here to get it: PCoIP Log Viewer Webstart
This was a big update, while it doesn't look like it on the surface the underpinnings of the parser are a major update (as you'll see below) so I expect there to be bugs. Please let me know what you run into. If you can please include a link to the log file causing the issue. Contact me here (via comments) or on twitter @rexremus and I'll do my best to get things fixed up. I hope you enjoy this update and get some good use out of the tool. If all you care about is the update – stop here, the rest of this post is going to dive into the details of the new parser and why I wanted to make this change. If that doesn't sound interesting, get out now while you still can!
New Parsing Framework
The Need for Modular and Extensible Parsing
The previous standalone parser rapidly grew into a mess. Why? Because I had developed an unhealthy desire to have one singular parsing "engine" that could handle anything thrown at it. There are several ways to do this, and the least desirable among them is really what the parser had become over the years – it was a singular parser instance with a ton of exception/quirk-checking to be able to deal with all variants of the PCoIP log files.
This is a trap that many of us fall into. You begin by writing what you expect will be a quick and dirty solution to a problem with no real thought of modularity, flexibility, or maintenance. Then people actually start using it, so now you have a community to support. A minor change needs to be made (like a small change to the content you are parsing) and you just lay it in, no need to refactor things for such a small change, right? Well, one small thing becomes 12, and some of those end up being pretty significant changes that are made worse because of previous changes that required some really hacky workarounds. And next thing you know, you are maintaining a complete mess.
This is where things were at in the standalone parser after the release of View 5.1. That was a major update and required jumping through so many hoops in the existing code I had vowed (to myself anyway) I would not do it again. If I had to change the parser again I was going to build it new, and take the lessons I learned from supporting the original version to make something easier to maintain going forward. I'd given up all hope of the log files staying consistent at this point – and by consistent I don't mean never adding new data, that's always to be expected; by consistent, I mean not altering the way existing data is presented and/or ordered so that only new data was required to be dealt with on a new release.
So once I had the time to deal with an update to 5.2 (after hearing from many people that 5.2 logs were not working) I began working out a simple, I hope, to maintain parsing framework.
The New Framework
The basis of the new framework isn't anything new or exotic, it's just a few changes that should help make things much more flexible going forward. At a really high level, I just decomposed the monolithic parser into a few component parts as shown below:
Here you can see a parsing component, a log file "model" component, and a formatting/output component. The flow of running a document through here works mostly as it's shown – the parsing component is responsible for converting the "raw" input into an intermediary container – the PCoIPLogFile object – which can then be fed into a formatting component that takes the intermediary container and "renders" it out to a new form.
All of these steps existed in the monolithic parser, but there was no easy way to extend or change any of the individual pieces. Here, each component represents a unique entity and much better encapsulates the specific functionality it is responsible for. Next we'll break down some of the individual pieces and talk about how they are implemented
PCoIPLogParser Component
The log parser box in the high-level diagram really represents a base class which can then be extended to create version specific parser instances.
I decided to base the parsing side of the new framework around a SAX-like implementation. If you are unfamiliar with SAX I will give a mangled, tremendously abbreviated breakdown of it here- SAX is used to parse XML documents and uses an event-based model. Rather than trying to load the entire contents of an XML document into memory (that is DOM parsing), SAX defines a set of methods that will be called at various meaningful points as the document is parsed such as startDocument(), endDocument(), and startElement(). These allow you to take action within the context of the event, for example creating your intermediary object in the startDocument() method, and cleaning it up in the endDocument() method. For extracting specific information from XML elements startElement() methods get passed information about the element that triggered the event which you can then examine and determine if it's an element you care about. SAX is great when you have to parse very large files as it's much more memory efficient than a DOM parsing implementation, and it gives you flexibility in that you can extend existing classes that implement all required methods (far more than I covered here) and only override the ones you care about – which may be as simple as just implementing the startElement() method.
When creating the new parsing framework I decided to use an abstract base class so that I could provide a handful of methods that I don't see changing very much, as well as house a few data structures and constants that I knew from prior experience would be used throughout the framework. I could have (maybe should have?) gone with an interface here and then created a base parser class off of that and then have all "real" parser implementations extend that base class, but it seemed like a wash in the end as I was not sure the extra flexibility would be of significant benefit. Building a parser for these log files is a non-trivial exercise, it's not just 1-2 methods you might tack onto another class and quickly flesh out. So in this case, I went with an abstract base class and handled as much core functionality as I could there.
Looking at a PCoIP log file we see that lines have a basic structure:
06/13/2013, 03:28:01.456> LVL:2 RC: 0 MGMT_SYS :UDP port values: base=4172, range=10, set=4172 06/13/2013, 03:28:01.456> LVL:2 RC: 0 COMMON :load_crypto_lib: FIPS mode enabled=0 06/13/2013, 03:28:01.488> LVL:2 RC: 0 MGMT_SSIG :(tera_xml_init) -- Software Build ID: soft_pcoip_rc_3_12 184.108.40.20651 06/13/2013, 03:28:01.503> LVL:2 RC: 0 COMMON :Initializing Winsock2 06/13/2013, 03:28:01.519> LVL:2 RC: 0 SCNET :PCoIP Soft Crypto Module Build ID: trunk 22.214.171.12458 06/13/2013, 03:28:01.846> LVL:2 RC: 0 MGMT_ENV :Setting ENV variable[ 7]: pcoip.tcp_port = 4172
If we break this down a little we see that every line starts with a timestamp, followed by a logging level, an RC code, a line "type" or category, and then the actual data or content of the line. I decided to model my SAX-like parsing around the line type element. The base parser will run through the file and call specific methods for each line type encountered (COMMON, MGMT_SSIG, SCNET, etc.) as well as methods for the file start and end. Each of these methods are defined as abstract in the base parser class and must be implemented in any concrete classes.
I then created a default implementation of a parser (DefaultPCoIPLogParser) that is based around parsing a View 5.2 log file. In this class I provide implementations of the methods for every line of "interest" in the log file needed to display it properly in the Log Viewer. This base implementation can then be extended when the log file format changes again, and only the methods that deal with the lines (really, the line types) that changed will need to be updated. This greatly simplifies dealing with new formats because there's no need to worry about backwards compatibility as there was in the monolithic parser – you can do whatever hacky, ultra-version-specific parsing tricks that make dealing with the current log file as easy as possible without any concern of breaking the parsing of a previous version and then let the existing methods of the parent class deal with everything else that didn't change. In fact, if the inherited method doesn't blow up or cause any other "damage" to the data placed in the intermediary object, you can call it from your overridden method, and then come back and "correct" or populate only the data pieces affected by the new log format – this way you don't need to copy/paste or otherwise replicate the existing parsing from the parent class and it saves you more time when creating the new parser version.
PCoIPLogFile Component
This is an intermediary object used to store the important data parsed from the log file. It's purpose it's really just to be a bridge between the input and output of the parsing process – a parser generates a log file object, and a formatter uses it as input.
This isn't to say the log file object is just a dumb container. It does contain a few methods, the most important of which is the validate() method. Because of the move to a SAX-like parsing front-end it became harder to determine if a log file was "good" or "bad" from within the parser alone. Certainly things like an individual line can be validated, but does one missing line, or one malformed entry mean the entire file is useless? Probably not, but it might, it just depends on which line it is and possibly the context around it. Rather than trying to put that kind of logic into what essentially amount to "stateless" methods within the parser (or going through a lot of effort to give them state) it made a lot of sense to just encapsulate the notion of "validity" into the object storing the entire document state itself. Once the parsing is done, the parsing workflow validates the log file object before passing it to a formatter. If the file is invalid, an exception is thrown and can be dealt with. This greatly simplifies error checking in that parser methods need only check for validity of a specific line (as that's all the context they can be guaranteed to have) and the log file object itself can check for overall validity given that it can assume the point where the validate() method is being called, it should be considered a "complete" representation of a valid file.
PCoIPLogFileFormatter Component
Just as the parser box in the high-level diagram represented an extensible component, the same is true for the formatter box. In this case though, I did go with an Interface as there's only a singular method to be implemented and it's quite possible to just tack it onto an existing class if the formatting required is not terribly complex. For more complex formatting it's likely a dedicated class will be built which can then be sub-classed as required to tweak or change behavior.
As you can see there's just one method – format() – that returns an InputStream containing the formatted output. This allows the resulting formatted content to be pretty easily stored to a physical file, or to be piped around and read from in memory. Java's streams (and all their variants) are fairly rich and well understood at this point so this seemed a pretty low-level and flexible result to get out of the formatter.
For the sake of the current work, I've created an XML formatter to allow for the existing visualization chain to be used in the viewer. But I can easily imagine an Excel based formatter to generate a physical file, or a JSON formatter to allow the parser/viewer to move to a cloud-based application and send data down to a browser or mobile device. All of these should be fairly easy to implement.
Gluing it all together – The Factory
Well, saying "all" might be a bit of a lie, but I wanted an easy way to make sure you always get the "right" parser, despite there only being one that's of any use right now. So I decided to build a ParserFactory to do that.
Basically, the Factory will scan the classpath looking for PCoIPLogParser implementations and then register them with itself to build a catalog of all available parsers. Within the app, when we need to parse a file we can then call the cleverly named getParser(logFile) method. This method examines the raw log file and extracts the "version" of the file based upon certain elements, it then queries every registered parser for it's supported log file version. When it finds a match, it returns that parser. Currently there's not much thought given to conflict resolution, e.g. what if more than one parser can handle a given version of file? But my thought on that is, within any given project, you probably wouldn't need more than one way to "parse" a file – you might want more than one way to format it, but really you only care about getting it into the PCoIPLogFile object and then working with it from there. So while more than one parser capable of dealing with a View 5.2 log file might exist, it isn't likely that you'd see them together in the same project where they might cause collisions.
The horrible diagram above shows (poorly) the basic flow of parsing a file:
- Get the file
- Ask the ParserFactory for a parser, passing it that file
- The factory determines the version of the file
- The factory queries all the registered parsers for their ability to parse it
- A valid parser capable of parsing the file is returned from the factory
- The parse() method is invoked on the file and the PCoIPLogFile object is returned
- The PCoIPLogFile is validated (this is where you can bail out before trying to format)
- If the PCoIPLogFile object is valid, it is formatted
- The returned InputStream is used as required – written to disk or passed to another method/process for display or further manipulation.
I might also consider a factory for the formatter classes as well, something where you can pass in a desired format and get the right formatter back – or be informed no such formatter exists – and go from there. But it seems rare outside of a web context (RESTful service) that any individual usage of this would require such flexibility so it wasn't high on my list. For now, you know what format you need and can just go with that. Anyway, I digress…
Wrapping it up
With the completion of this new parsing framework, parsing PCoIP log files going forward should now be easier to deal with. Still frustrating, but easier. At the very least, there is now a level of encapsulation and separation of duties that was missing from the organically "grown" monolithic parser that started it all. The real test will be when the log viewer breaks again, as it inevitably will, and I am required to make the first updates. That's when I'll know if this was worth doing. But in my view, it's fun to make updates like this. Is my design perfect? Hardly. Are there probably a dozen libraries/frameworks I could have tapped to build this in? Almost certainly. But they often add a lot of baggage and "weight" and if you didn't build your entire project against those frameworks it often means the benefits are limited or that you end up starting over. Building this from scratch was satisfying on multiple levels. It's something I had wanted to do for a while, so I have the satisfaction of completing it. It's only as large and complex as it needs to be – which isn't very much of either. And lastly, it should allow me to support the users of this app better than I have been able to do in the past.
In the end, that's all I really wanted.
Dynamic PCoIP in View 5.2
Those of you who attended VMware Partner Exchange 2013 and came to my session on Dynamic PCoIP will be somewhat versed in this topic, and if you've stopped by the excellent myvirtualcloud.net and read Andre's post on View 5.2 you may have seen my comment there and will also be up to speed.
But for those who have managed to miss out on both of those things, I wanted to recap some items here.
What Changed?
"PCoIP GPO settings take effect immediately when changed (host side only)"
This was announced with the launch of View 5.2 as a new PCoIP feature. But there are a few problems with this, and a lot of confusion around it (even internally to VMware).
To briefly recap the information I left in the comment at myvirtualcloud.net-
This feature allows a limited number of PCoIP settings to be applied to the registry (via whatever method) and to take effect immediately within a currently running PCoIP session. So, specifically for something like tuning, you would be able to change parameters and it would not require a disconnect/reconnect sequence for those settings to take effect. This is pretty awesome!
So what's wrong?
Well, the press releases just generically say "PCoIP GPO settings take effect immediately" – but do nothing to specify WHICH settings. Further, some issues were introduced between the early 5.2 beta and the RTM code for View 5.2 that caused this feature to only "work" for a really small subset of parameters. In my opinion, this basically renders a potentially awesome feature mostly useless.
So, in a perfect world, what options should take effect immediately? As far as I know, the following were planned for in the original drop:
- Disable Build-to-Lossless
- Max session bandwidth
- Session Floor
- Max initial image quality
- Minimum image quality
- Max FPS
- Audio bandwidth limit
- Logging level
What options actually work in the 5.2 GA release (based upon my experience)?
- Max FPS
- Audio bandwidth limit
Slightly less useful right? So the feature is in there, but it's not really implemented across enough options to make it terribly viable.
Why does this matter?
Having this feature added to PCoIP has been a long-standing request of mine. I've been building tools (sporadically, I admit) for PCoIP for the past 3 years now, and I've always maintained a "vision" of being able to control the protocol in real-time for both users and admins and then building new tools around that.
One tool I had started work on, but have put on hold is a real-time tuner:
This tool allows you to view content and tune at the same time; to see the subjective impact of tuning at the same time as the objective impact on bandwidth, loss, and latency. I've been wanting to write this tool for 2+ years! And I did, mostly, but you know what? It's of absolutely no use to anyone right now, so I didn't finish, and I won't be releasing it yet.
I also have several ideas on how to improve the PCoIP Configuration Utility. With this feature fully implemented, I can create a version of it that not only stores and applies profiles, but that could do so in response to contextual data from the client. Connecting via a mobile device? Automatically apply this profile. Connecting across the WAN? Automatically apply the WAN profile. This could be keyed off IP, MAC, User, Domain – whatever! If it's a piece of information that can be read on the desktop, it can be used as a condition to apply dynamic tuning.
That would be cool wouldn't it?
That's a wrap
So, to wrap this up, I'm pushing hard internally to get the initially planned set of dynamic parameters fully implemented. I am hoping to see it in the next release of View, but I can't say if that will happen with any certainty, probably, it won't. Still, membership has it's privileges, so I have access to "working" code for these changes and I wanted to share a video I had intended to show at PEX 2013 but which a last minute computer failure forced me to abort. I hope it gives you a taste of what's to come once these features are fully implemented.
I have embedded the video here for ease of access, but since youtube is only aware of video in 16:9 format you can't view the content at 1:1 which means it's far harder to see the visual artifacts when aggressively tuning the session. Because of that I am also going to include a download link for the source MP4 video to allow for true 1:1 playback and better subjective visual inspection.
Also, there's a slight jerkiness to the video at times, I want to be clear that this is an artifact caused by the software-based capture method I am using and is NOT present when interacting with the View session natively in the View Client. As soon as a DVI frame-grabber capable of high-resolution capture at 30+ FPS goes on sale for less than a few grand, I will get one and this artifacting will go away, until then – sorry :-/
Direct download: Dynamic PCoIP Tuning Video
Thanks, and sorry for the lack of content recently, I am hoping to get some blog and software updates out the door in the coming weeks.
PCoIP Configuration Utility Release – Version 1.0
At VMworld US 2012 in the EUC2620 session, I spoke about both the PCoIP Log Viewer, and PCoIP Configuration Utility. Unfortunately, the "cool" stuff in the PCoIP Configuration Utility that I showed in that session wasn't publicly available. Those features were/are being utilized inside a few select VMware customer environments to gather some feedback but I had not posted the code here at MindFlux – until now.
So, here it is! The new and improved PCoIP Configuration Utility.
I have decided to remove the beta moniker and call this code drop Version 1.0. I consider this a decently "feature complete" drop of the code, but as with all software, it's never done, and bugs almost certainly remain. Unlike Google though, I feel compelled to take things out of beta after a reasonable amount of time :)
What's new
You saw some of this in my previous sneak peek post but I'll recap it all here. For the original feature list please review the initial launch posting here.
- PCoIP Connection Health Monitoring (See screenshots)
- Monitors various PCoIP connection stats and determines an overall health score
- Health status can be easily determined via the systray icon with states ranging from "green" to "red"
- A new health status popout that shows the metrics being tracked and their current health "scores"
- Profile Tooltips
- Hovering over a profile within the "Apply Profile" menu will now show a tooltip with the detailed settings for that profile
- PCoIP Server CPU Utilization
- This should now be accurate, previously, as load increased this value would scale out of proportion to the actual load leading to inflated CPU utilization values
- Session disconnect awareness
- The utility now detects when there is not an active PCoIP session and when there is not, it enters a "sleep" mode that will consume less CPU than the active polling mode. Why burn CPU if there's no user connected right?
- Upon re-connection the utility will cleanly reset and resume stat collection in active polling mode. Previously, stats were not properly reset after a disconnection event causing some ugly numbers in the stats popout window.
Requirements, Issues, Implementation details, etc.
- .NET 3.5 is required
- VMware View 5.0 or 5.1
- Tuning profiles and last used profile are stored in HKCU and in theory should be able to roam with a user to whatever desktop they happen to land on – if you have something setup to allow the profile to roam, that is.
- The utility will request admin access – it needs this to be able to write to HKLM which is where the PCoIP settings are read from. You may need to get clever while launching it if you want to avoid UAC nagging you about it.
- This seems to come up often in the comments and in other feedback, right now there's not an easy fix for this. I have reached out to Teradici to get these settings moved under HKCU – we'll have to see where that leads. This CAN be fixed but most options are kind of a "cure worse than the disease" solution that I'm not ready to move towards just yet.
- GPO Conflicts
- If you plan to use this tool to manage the tuning settings of a desktop you should avoid also setting tuning parameters via GPO on that desktop. GPO can still be used for things like clipboard sharing policy, or USB device policy, just avoid any of the settings controlled via a profile.
You can grab a copy of the utility here: PCoIPConfig.exe
Next Steps
There are a lot of existing enhancements left for the current tool. But the biggest issue still remains the required disconnect/reconnect. There are some potentially promising developments along that path though, so stay tuned. Please share your thoughts for enhancements and/or bugfixes in the comments.


text:
PARIS - Five major champions successfully made their way through the first round of the French Open on Sunday's opening day. One didn't.
Sam Stosur and Svetlana Kuznetsova were first up on the main two courts, and both won in straight sets. Juan Carlos Ferrero and Juan Martin del Potro soon followed on the same courts, and with similar results. And 2008 French Open champion Ana Ivanovic then made it 5 for 5.
The lone loser so far was Andy Roddick, the 2003 U.S. Open champion from the United States.
"It's a bit of an early start, but always nice to get through it now," said Stosur, the U.S. Open champion who beat Elena Baltacha of Britain 6-4, 6-0. "You have the whole day and whatever else to recover and, yeah, enjoy."
Roddick lost to 88th-ranked Nicolas Mahut 6-3, 6-3, 4-6, 6-2, exiting in the opening round of a Grand Slam tournament for the first time since 2007. The 26th-seeded Roddick is 7-10 this season, 0-4 on clay.
Seven-time Grand Slam champion Venus Williams was also playing Sunday. Williams is playing in a major tournament for the first time since revealing she was diagnosed with an autoimmune disease that causes fatigue.
None of the top three men was in action on Day 1. Top-ranked Novak Djokovic and Roger Federer will be on court today, while Rafael Nadal is slated to begin his attempt for a record-breaking seventh French Open title on Tuesday.
The ninth-seeded Del Potro made his way into the second round despite some problems with his left knee, beating Albert Montanes 6-2, 6-7 (5), 6-2, 6-1.
The 2009 U.S. Open champion played with tape on his knee early in the match. Del Potro then added wrapping after a massage from a trainer following the second set.
"It's a problem when you can't find your balance like you're used to, but I'll use these few days of rest to get better," Del Potro said. "If I go on the court, it's because I feel good. I want to continue playing."
Del Potro reached the semifinals at Roland Garros in 2009, but lost to eventual champion Federer in five sets. A few months later, the Argentine defeated Federer in the U.S. Open final.
Ferrero, the 2003 French Open champion, beat Jonathan Dasnieres de Veigy of France 6-1, 6-4, 6-3. The 32-year-old Spaniard is one of 37 men in this year's draw that is 30 or older, an Open era record for Grand Slam tournaments.
"I saw myself in the mirror, and when I walk on the court I don't think about whether I'm younger or older. The only thing I try to do is play well," Ferrero said. "And I'm at Roland Garros, and the idea is to play well today."
Jo-Wilfried Tsonga, the highest-seeded player in action on Sunday at No. 5, also advanced. The Frenchman defeated Andrey Kuznetsov of Russia 1-6, 6-3, 6-2, 6-4.
Fabio Fognini of Italy was the first man to reach the second round Sunday, beating Adrian Mannarino of France 6-0, 7-5, 6-1. No. 21 Marin Cilic of Croatia was next, defeating Daniel Munoz-De la Nava of Spain 6-4, 6-4, 7-5.
Kuznetsova won the French Open title in 2009 and the U.S. Open in 2004 but is seeded No. 26 this year. Against Mirjana Lucic of Croatia, the Russian faced little trouble despite being broken twice in the second set. She eventually won 6-1, 6-3.
"I love this tournament. Even before I won I always enjoyed coming here," Kuznetsova said. "It's (a) special atmosphere here."
Ivanovic beat Lara Arruabarrena-Vecino of Spain 6-1, 6-1. The 13th-seeded Serb won her only major title at Roland Garros in 2008, but then lost in the fourth round a year later. She fell in the second round in 2010, and then lost in the first round last year.
No. 10 Angelique Kerber of Germany and No. 20 Lucie Safarova of the Czech Republic also advanced to the second round, along with American players Melanie Oudin and Irina Falconi.
The French Open is the only Grand Slam tournament that starts on a Sunday. The other three all start on Mondays.
"I don't think it's too big a deal now that it's more of a proper schedule," Stosur said. "I think the first year there was only a handful of matches, and, yeah, if you were on the schedule then, it really didn't feel like the tournament started. Nobody else was thinking that the tournament had started."


text:
Check out Why I don't host my own blog anymore.
I mentioned it to a friend and he immediately piped in "Oh that guy did it wrong, he shouldn't care about KeepAlive, he needs FastCGI".
Ok so the guy "messed up" and misconfigured his blog. Zigged instead of zagged. Bummer.
But it doesn't have to be this way. Right now we offer Wordpress as a juju charm. This lets us deploy Wordpress with Mysql in 4 commands.
However if you look at the db-relation-hook we don't do anything special, we create an apache vhost and set it up for you. While this is simple, there's no reason we can't make this charm be a turbo charged deployment of Wordpress. Let's look at some of the recommendations we see on his blog and on HN:
- A simple caching plugin would have quickly fixed this for you.
- In my stacks I always use nginx in conjunction with Apache to handle as much of the static content load as is possible and that lifts a huge weight from Apache. Next up is to always use a bytecode cache like Xcache or APC, these help give a huge boost in performance.
- But then you hit a wall, next up are limitations in WP SQL and MySQL, these can be helped by messing with the queries and using Memcached also helps to significantly boost the DB performance here.
- I had similar nightmares to you for a long time with Apache/PHP/WP, then finally put Varnish cache in front of the whole thing.
- And someone recommends just shoving the thing in Jekyll and serving that.
I'm sure everyone will have an opinion on how to deploy Wordpress. From an Ubuntu perspective, we ship the wordpress and mysql packages, but that only gets you so far. It's still up to you to configure it, and as this guy proves, you can mess something up. Wouldn't it be nice if we could collect all the experience from people who are Wordpress deployment experts, put that in our charms and just give people that out of the box?
We could use nginx in the Wordpress charm, with FastCGI, we can certainly add relations to make varnish and memcached know what to do when they're related to wordpress. And/or just "juju add-relation jekyll wordpress" and have that Just Work.
These are the kinds of problems we're trying to tackle with juju. Will it be totally perfect for everyone's deployment? Of course not, that's impossible, but we can certainly make Patrick's experience more uncommon. People will always argue about the nitnoid implementation details, but we can make those config options; the point is that we can share deployment and service maintenance as a whole instead of hoping people put the lego blocks together in the right order.
Interested in turning a plain boring charm into something sexy? I've filed the bug here, let us know if you're interested.Read more