On Mon, May 18, 2015 at 7:06 PM, Sven Van Caekenberghe <s...@stfx.eu> wrote:
> > > On 18 May 2015, at 12:13, Guillermo Polito <guillermopol...@gmail.com> > wrote: > > > > Hi Sven, I'll take that into account. I did not think about using an > empty host/port pair, maybe because of the extra slash. > > > > Also, I do not need to convert the file name to a file reference. That > is done in sqlite by the sqlite library itself, so it's less work for the > driver. The only need I need to do is: > > - for nbsqlite get the file name > > - for opendbx get the full file name and split into directory + file > name because they are two different arguments for the library. > > I think that if you want to view (part of) a URL as a file system path > and/or if you want to work with that path (splitting it directory/file for > example), converting to a file reference is a good idea. ZnUrl can do file > interpretation to some degree (#directory & #file, #isDirectoryPath & > #isFilePath), but not very well (it is not its primary application). > > ZnUrl>>#path is actually not the best selector to use. It uses the > internal representation. Like #directory & #file, #isDirectoryPath & > #isFilePath, these leak some internals. ZnUrl>>#pathString is better, and > will give you a leading $/ while encoding everything correctly. > > Also, relative File URLs simply do not exist. This sparked my interest to read RFC3986 ( https://tools.ietf.org/html/rfc3986#section-5.2.4) which says: A relative reference that begins with a single slash character is termed an absolute-path reference. A relative reference that does not begin with a slash character is termed a relative-path reference." The path segments "." and "..", also known as dot-segments, are defined for relative reference within the path name hierarchy. They are intended for use at the beginning of a relative-path reference to indicate relative position within the hierarchical tree of names." Within a representation with a well defined Base URI of "http://a/b/c/d;p?q"; a relative reference is transformed to its Target URI as follows. "g:h" = "g:h" "g" = "http://a/b/c/g"; "./g" = "http://a/b/c/g"; "../g" = "http://a/b/g"; "/g" = "http://a/g"; So slightly as an aside, this makes me wonder if we should consider that when the Image is a opened as a file, its Base URI can be considered to be 'file:///b/c/Pharo.image' such that its reasonable to have the following relative references transformed as follows: 'g:h' asUrl asString "--> 'g:h' 'g' asUrl asString "--> 'file:///b/c/g' './g' asUrl asString "--> 'file:///b/c/g' '../g' asUrl asString "--> 'file:///b/g' '/g' asUrl asString "--> 'file:///g' Effectively, the default scheme is #file rather than nil, as it is currently. RFC3986 5.2.2. "Transform References" shows a non-strict case where it seems that following intuitive example is valid 'file:///./g' asUrl asString "--> file:///b/c/g' " per this line... T.path = merge(Base.path, R.path); RFC3986 5.1.2. "Base URI from the Encapsulating Entity" indicates we could consider the Base URI for the sqlite3 scheme to derive from the Image's 'file:///b/c/Pharo.image' URI to be... 'sqlite3:///b/c/Pharo.image' such that per 5.2.2. the following would be valid... 'sqllite3:///./g' asUrl asString "--> sqllite3:///b/c/g' " All that is from a patchy skim of RFC3986, so maybe I got it wrong, but maybe its a view worth considering. > But there is #withRelativeReference: which follows the relevant specs > (check the tests). > > FileReference should also deal better with platform issue, ZnURL is much > more abstract, by definition. > > I hope this makes sense ;-) > > > Now, having a look at what we can do with znurl > > > > In windows it looks that we are ok > > 'sqlite3:///c:/myDirectory/myfile.db' asUrl path. > > "'c:/myDirectory/myfile.db'" > > 'sqlite3:///c:\myDirectory\myfile.db' asUrl path. > > "'c:\myDirectory\myfile.db'" > > See also #testWindowsDriveNamesInFileUrl > > > But in linux even if I put extra slashes it keeps removing them... And > it makes difficult to recognize relative from absolute file paths: > > > > "Relative path c/myDirectory/myfile.db OK" > > 'sqlite3:///c/myDirectory/myfile.db' asUrl path. > > "'c/myDirectory/myfile.db'" > > > > "Absolute path /c/myDirectory/myfile.db not OK" > > 'sqlite3:///c/myDirectory/myfile.db' asUrl path. > > "'c/myDirectory/myfile.db'" > > > > Adding Slashes > > 'sqlite3:////////c/myDirectory/myfile.db' asUrl path. > > "'c/myDirectory/myfile.db'" > > > An intuitive semantic would be... ''sqlite3:///./c/myDirectory/myfile.db' asUrl pathPrintString "--> /my/pharoImagePath/c/myDirectory/myfile.db" > > Another concern is that garage as it is works in Pharo 3, 4 and 5. Then > if we update Zn I'll have to add Zn to my dependencies and load the correct > version accordingly, what do you think? (I prefer that to back porting) > > Just depend on the latest stable release of Zinc, it is (still) supported > for 2.0 and up. > > > Guille > > > > > > El lun., 18 de may. de 2015 a la(s) 11:27 a. m., Sven Van Caekenberghe < > s...@stfx.eu> escribió: > > Hi Guile, > > > > > On 18 May 2015, at 10:48, Guillermo Polito <guillermopol...@gmail.com> > wrote: > > > > > > Well, I wanted in general to have a single easy-to-learn way to build > a database connection string for all drivers. > > > > > > [driverid]://[host][:port]/[databasename]?[properties] > > > > > > Then, for sqlite I would like to have: > > > > > > sqlite3://myDirectory/myfile.db > > > > > > or > > > > > > sqlite3://memory > > > > > > Now, for Garage 0.1 I was using ZnUrl to parse the connection strings > and that is not working for urls like the following because if the schema > is not 'file' then the parser fails to to transform the port (an empty > string in this case for the parser) to an integer > > > > > > sqlite3://c:/myDirectory/myfile.db > > > > > > In bleeding edge I am using an alternative parser that does no > conversions and allows urls like that one. > > > > I understand the reasoning here, but I would suggest that you at least > consider changing your mind. Over time, a lot of work went into ZnUrl, and > many people used it and helped fixing many problems. Recently we tried to > improve the situation for special schemes a bit (for git URLs). We're not > yet there, but you (your use case) could help improving the situation. > > > > I tried to take a principled approach regarding the specs (not that > there is one clear spec, haha), but edge cases should still be possible. > > > > Consider the following: > > > > 'postgresql://localhost:14433/test-db?username=john&password=123456' > asUrl. > > 'postgresql://john:123456@localhost:14433/test-db?encoding=utf8' asUrl. > > 'postgresql://localhost/default' asUrl. > > > > 'sqlite3:///myDirectory/myfile.db' asUrl. > > 'sqlite3://memory' asUrl. > Would memory have a hierarchical structure? i.e. if I wanted to run two sqllite3 instances in memory? > > 'sqlite3:///c:/myDirectory/myfile.db' asUrl. > > > > According to me, these all parse correctly. Of course, ZnUrl does not > know or understand what is possibly special about any particular scheme > (apart from HTTP(S)). Still, it is just an object that can be manipulated. > > > > The default port can be computed along the lines of #portOrDefault, > maybe we could add a #portIfAbsent: ? > > > > Conversion to a file references can be done as follows: > > > > 'sqlite3:///c:/myDirectory/myfile.db' asUrl > > copy scheme: #file; asFileReference. > > > > Which basically reads as: 'I know this is not a file:// URL proper, > still I want to interpret it as if it were one'. Maybe we could add a > #forceAsFileReference ? > > > > Anyway, you get the idea. You know I am willing to help. > > > > Sven > > > > > > > > > > Looking through Zinc I notice that the schemes are symbols. Any plans to make these classes? To maybe(?) make it easier to extend to other schemes ( http://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml) ? Or do you consider that outside the scope of Zinc ? cheers -ben
