On Nov 11, 2007, at 11:08 AM, Christiaan Hofman wrote: > > On 11 Nov 2007, at 7:20 PM, Adam R. Maxwell wrote: > >> I actually added that basePathForAliasFile: method just to avoid >> another temporary URL conversion in the save loop. >> >> Which brings up another point. NSDocument converted everything to >> use >> NSURL instead of paths in 10.4, but the rest of Cocoa seems to use >> paths (NSFileManager, the new NSWorkspace stuff for UTIs). I >> complained to Apple about this and never heard back. >> >> Given that, I'm not convinced that we should use NSURL as a path >> replacement. It would be nice to pick one and stick with it, so we >> avoid the URL<->path conversions as much as possible. >> >> What should we do? The only good thing about URLs is that they're >> easy to convert to/from FSRefs, as far as I'm concerned. However, >> you >> can't use a ~ in a URL, and paths are easier to work with for >> relative >> paths. >> > > That's the reason I used a URL for the delegate method.
Could base64StringRelativeToPath: use an absolute URL as well? I haven't looked at the file code for a couple of weeks. > > >> Currently we support paths or string URLs in BibItem, and that code >> drives me crazy (some uses paths, some uses NSURL, some returns URLs >> as -absoluteString...). >> >> My present thinking is that we should >> >> - use NSString paths in BibItem > > Like where? Everywhere we use NSURL* or -[NSURL absoluteString] to refer to a file... > > >> - create the file objects with paths > > I'm not sure, if we (ever) want to use both local and remote URLs in > the file view I think it's better to use just URLs. The only place I think it can be useful is in the main window view, since you can do a quick look at the URL or drag/drop it. > > >> - use NSURL for remote URL >> - only allow a one-time upgrade of a current file (i.e. ditch the >> current path and URL handling setup) >> >> That last point is likely to be unpopular. I'm not sure if I like it >> myself, but the more legacy code we support, the harder it will be to >> make file objects work properly. >> > > Moreover it would be fragile not to do it. Files would be re-added > all the time, in particular if there are files that could not be > resolved. Fragile to keep the legacy support in there? I concur with that. The only real loss is human-editability with a text editor, as long as the alias file preserves the original path when the file isn't resolved. >> I originally used paths for FileView, but switched to URLs to allow >> representing non-file URLs. This isn't a big deal, since returning a >> URL from a file object is easy, so doesn't need to drive any BD >> internal changes. >> > > I think it's better to use URLs, as it also can represent remote URLs. Okay, I don't have a real problem with that. Right now we have a bunch of methods that are variations on local[File|URL]Path... and I can imagine some future developer looking at that and wondering what we were thinking. We also have suggestedLocalUrl which returns an NSString, so if we can unify all of this stuff, I think we'll be happier in the long run. -- adam ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Bibdesk-develop mailing list Bibdesk-develop@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bibdesk-develop
