генерал Пурпоз wrote: > Hello William, > > Monday, January 29, 2007, 10:03:56 PM, you wrote: >> It looks like your QNX4 compiler isn't modern enough to support apr. >> I don't have a clean solution to suggest :( > [rant] > Pity... > I thought the "Portable" in the project's name would oblige to a some > degree... And I'm still in APR, APR-UTIL is far less friendly... > Consider the "tm_usec" in the "struct tm"! > [/rant]
Yes - apr and apr-util are designed for modern operating systems. We had deliberately chosen not to provide full interoperability with legacy OS and micro-OS's. There are a number of portability solutions out there, what distinguishes APR is (we hope) it's usefulness at authoring server daemons and other applications that demand modern features. For example, ACL's and interoperatibility with OpenSSL are two features we hope to introduce in the near future (OpenSSL is already being leveraged on our development trunk and in the coming 1.3.x versions). These are the sorts of features that these applications demand. > (Offtopic: there is hope, the OpenWATCOM is being ported too, with > full int64 support) WOOT! I'm glad to hear this; there are many factors in modern applications which demand huge-integer representation (apr_time_t, for example). >>> I'm tempted to see the "//node-ID/" as the "C:/" on MS-DOS, am I >>> wrong? >> Similar, yes. But I'd suggest it's more like //machine/share/ syntax >> on MS-DOS. > I'm yet to understand what does that interpretation mean to me on > QNX4. > >> The root of the local node could reduce //0/ to /, yes. > Does this mean that APR will not work across the network? On QNX4 a > user may refer to a file|folder on another node. The porting of APR is > the part of my attempt to port the SVN. So, it would be great to be > able to send "svn checkout [EMAIL PROTECTED] > //other-node-ID/path/to/a/working/dir"... Well, this isn't actually a flaw since you can't accomplish this (moving from box X to box Y and anticipating a proper representation. C:/ isn't represented as //thisbox/local-C-share either.) >>>> If they pass the "//local-ID/foo" path, they better get back "/foo". > In the light of the above - if I get the fullpath of local resource > I'll return "/foo" but if I get non-local "//node-ID/foo" - should I > keep it as is? > //0/foo =========== /foo > //my-node-ID/foo == /foo > //other-node/foo == //other-node/foo > Will this break anything in the APR? I wouldn't want to reduce the second case, we don't do that on any other platform. But I'd DEFINITELY agree //0/ should be reduced to /. //0/ They are identical, and / is easier to write. In fact, Win32 should probably learn to reduce //?/C:/ to C:/ if we aren't doing that now (we may be doing so.) Bill
