On reflection, it sounds like we agree about everything apart from whether to store system-specific or standardised paths internally (we may disagree about what the API implies in this regard too ... but I think the principle is the main issue).
Pretty much. The principle, though, has implications on the whole engineering...
We both seem to believe in much the same objectives, but disagree about how to achieve them.
Yes.
I'll try to clarify my reasoning in principle ... I think we want to be able to write portable code with minimal knowledge of filesystem differences, and to me it makes sense to say to application developers -
Work to a single set of behaviors and use standard, simple mechanism for
converting paths to/from the standard on the infrequent occasions when it is necessary to read in or write out local paths.
To you it makes sense to say - determine what system your app is running on,
and expect to use paths in the local format. Stick to the standard methods
for path manipulation and there will be few occasions where you need to
adjust your code to do things in a system specific way.
A reasonable characterisation of our positions.
My background is very much one of distributed programming, where an application will deal with input from many machines simultaneously. From that perspective, having different path representations on different machines is horrible. However, I do realise that it is an unusual perspective, and the vast majority of programs don't have an isuse with this.
Actually, coming from SCADA & Process Automation, heterogenous multi-nodal systems aren't alien to me at all.
I'm not sure of your requirement, here. I'm wondering why different machines are senting path representations for their local file system.
If the situation is that they're sharing storage I can see why you'd send a path but then that is a path into the shared space. I'd have thought it'd be easy enough to send references relative to the mount point in which case your Win32 code would ensure it sends the path in an acceptible way for the transfer. The winbox won't share a mount point and will probably use UNC in this case so you are encountering the semantic differences.
While my feeling is that the two approaches are fairly evenly balanced (leaving aside distributed systems, and the fact that we have one system already working in the libraries, and consideration for the existing application codebase), I'd like to hear what other people think about the general prionciples.
So would I. Hence I've been quiet for a bit.
Speak up, people.
Regards, Sheldon
_______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev