Re: [cdt-dev] Remote EFS designs

[James Blackburn <jamesblackburn@xxxxxxxxx>]

2009/5/28 Sergey Prigogin <eclipse.sprigogin@xxxxxxxxx>:
> On Thu, May 28, 2009 at 1:42 PM, Doug Schaefer <cdtdoug@xxxxxxxxx> wrote:
>>
>> Something I'm beginning to understand is that IPath is not intended for
>> file system paths. While it may work in some cases, it is really meant for
>> workspaces paths.
>
> I disagree. IPath has getDevice() and isUNC() methods that don't make any
> sense for resources inside workspace. IPath has problems and limitations but
> so are other competing file representations (java.io.File and URI)

Well I agree that IPath can be easier to use. However it's been
basically deprecated by the Platform guys to support EFS.  So apart
from workspace relative stuff, I think URI is the lowest common
denominator, is it not?

James
>>
>>
>> To represent file system paths, you should really be using java.io.File
>> for local paths, or URIs more generally.
>>
>> Doug.
>
> -sergey
>>
>>
>> On Thu, May 28, 2009 at 4:31 PM, Andrew Gvozdev <angvoz.dev@xxxxxxxxx>
>> wrote:
>>>
>>> Hi James,
>>>
>>> IPath <==> URI conversions are not always properly handled
>>>
>>> Consider the following example:
>>>
>>> IPath path = new Path("c:", "/a/b/c"); IFileStore f =
>>> EFS.getLocalFileSystem().getStore(path); then print out f.toURI() you get
>>> something like: file:/path/to/workspace/c:/a/b/c
>>>
>>> Lack of Windows path support
>>>
>>> There is no device field in a URI. I.e., it's not legal to have c: in a
>>> URI.
>>>
>>> Is there any eclipse EFS URI specification to refer? It seems to be legal
>>> to have ":" character in URI according RFC 2396. You may need to escape it
>>> in case of conflicts with schema but it does not look that it is the case in
>>> our case.
>>>
>>> Building projects: IResources -> Command Line Arguments
>>> Include folders could be expressed using URI. So could build location in
>>> project properties. I am not sure how far we want to go with that for now,
>>> but suggest to add as part of collecting requirements.
>>>
>>> Resolving absolute paths
>>> There is one more case deserving to be considered. The absolute path
>>> could be outside of the project but in the workspace as part of some other
>>> project. Not sure how important it is for generating makefile but it is very
>>> important for parsing error output and assigning markers.
>>> >Hi All,
>>> > Feel free to edit / bring up issues you think I may have missed.
>>> I don't think All has permissions to edit the page. If so could you
>>> instruct how to do that.
>>> Andrew
>>>
>>>
>>> On Thu, May 28, 2009 at 12:08 PM, James Blackburn
>>> <jamesblackburn@xxxxxxxxx> wrote:
>>>>
>>>> Hi All,
>>>>
>>>> We had a quick brainstorm about generating markers for build output
>>>> for the case of remote builds using RDT, and how this might interact
>>>> with e4 style flexible resources (effectively glorified linked
>>>> resources).  I don't think there's much of issue apart from: make
>>>> ErrorParserManager support URIs.
>>>>
>>>>
>>>> I've added some detail to the EFS wiki :
>>>> http://wiki.eclipse.org/PTP/designs/remote/EFS adding two sections:
>>>> 1.1.1 FileStore layers & 1.4 Implementation Assumptions.
>>>>
>>>> This documents what was discussed. i.e. converting IResources to paths
>>>> for the builder (which is done now) & the reverse: converting Tool
>>>> output paths to IResources.
>>>>
>>>> The approach outlined is that any IResource may be linked, and may
>>>> point to an arbitrary EFS URI.  The EFS URIs, are assumed to map to a
>>>> filesystem tree of the same structure (this assumption is currently
>>>> made by the RDT tools and elsewhere).    The job is then converting
>>>> Console output paths to locationURIs to resolve.
>>>>
>>>> This approach allows fully flexible IResource trees (using Serge's e4
>>>> work for ease + a few minor tweaks to ManagedBuild), and is working
>>>> well here.  I see no reason why this shouldn't work nicely with RDT as
>>>> it does for local file systems.
>>>>
>>>> Feel free to edit / bring up issues you think I may have missed.
>>>>
>>>> Cheers,
>>>>
>>>> James
>>>>
>>>
>>> _______________________________________________
>>> cdt-dev mailing list
>>> cdt-dev@xxxxxxxxxxx
>>> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>>>
>>
>>
>> _______________________________________________
>> cdt-dev mailing list
>> cdt-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>>
>
>
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>
>