You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently Artifacts need to use Path instances to point to the files in the local file system that constitute the product "code" base. This makes sense for some specific cases, for example for the ECCO service that provides a "repository" like functionality where the files that constitute a product are kept in a local folder.
In the general sense, ECCO should support files located "anywhere" (e.g. web servers, ftp servers, network drives, etc.). For this I think the best approach is to change the Path to a URI.
If this is defeninetly not the case and things must be kept local, then the generic parameter from Artifacts should be removed and the Path interface "hard codeded".
The text was updated successfully, but these errors were encountered:
agreed, imo the interfaces are too specific to file io and should be refactored into something more generic anyway. The basis of a, e.g., a reader, is, to take an object, convert it to nodes, and return the nodes. It shouldn't matter if the object is a file or something else entirely.
Currently Artifacts need to use Path instances to point to the files in the local file system that constitute the product "code" base. This makes sense for some specific cases, for example for the ECCO service that provides a "repository" like functionality where the files that constitute a product are kept in a local folder.
In the general sense, ECCO should support files located "anywhere" (e.g. web servers, ftp servers, network drives, etc.). For this I think the best approach is to change the Path to a URI.
If this is defeninetly not the case and things must be kept local, then the generic parameter from Artifacts should be removed and the Path interface "hard codeded".
The text was updated successfully, but these errors were encountered: