From: William P. <wil...@ya...> - 2010-03-19 03:26:08
|
On Mar 18, 2010, at 9:06 PM, Vladimir Gapeyev wrote: > (2) An ominous message when Phylowidget loads: "An applet requires access to your computer. The digital signature could not be verified." It does sound a little scary. Is there a workaround, or would we have to purchase something from Verisign (or whatever)? > (3) Havoc from purls. Since sometime recently, *some* links that are crucial for the functionality of the application contain purls instead of urls pointing to the current application instance. Due to the current resolution of the purls, this makes all instances to eventually drift to the treebase.nescent.org instance. This should not be a problem when we serve from production, right? > Consequently, I think the only legitimate purl occurrences are the places where the purls are spelled out in text Good point. Let's make a mental note of this -- but for now it's probably not a show-stopper. > - The temporary study 10215, which was used for migration uploads, is associated with 492 files in study_nexus file. This might be the missing files, but isn't the number too low? there were only 99 studies in the last migration -- so 492 files (some matrices others blocks of trees) sounds about right. > - On the other hand, migration dumps only contained tree or matrix files, while original files are expected to be mixed in general, right? Then the migration was not supposed to put original files into the DB, how could it? For TB1 data, we don't have the real original files, so we intended to use the migration files instead. We should fix this, but not a show-stopper IMO. > - I checked a few studies that do have files in study_nexusfile. E.g., #823. They do return these files through the the "Download original file" link, but the tree and matrix entries for these studies do not offer links to download NeXML and RDF. I see the NeXML and RDF links: http://treebase.nescent.org/treebase-web/search/study/matrices.html?id=823 > With (3), we can go to production tomorrow by just re-pointing treebase.nescent.org to the production database. However, after that we will not have an instance where to test newer versions of the application (since many links on treebase-dev.nescent.org resolve, via purls, to treebase.nescent.org). If it were up to me, I'd prefer the purls issue resolved before Treebase goes live. I can probably track down and correct the wrong links myself, within about a day of work. However, my understanding of the role of purls was not orthodox in the past. I'm with you regarding fixing the purls, but maybe that's not a show-stopper seeing as the main benefit is to make it easier for us to de-bug the dev deployment. bp |