[Pharo-project] [RFC] Zinc-Resources
Hi, This is request for comment on an idea, as suggested by Pavel because he needs it for his kernel building/packaging work, but also in line with several existing issues related to URL, URI and mime types. The idea would be to create a new package called 'Zinc-Resources' or maybe 'Zinc-Resource-Description' to contain just ZnUrl and ZnMimeType (and their supporting clases if any). The packaging requirement would be that the new package can only depend on core Smalltalk and not on any IO related packages such as File, Network or HTTP (Zn). Afterwards, File, Network or HTTP (Zn) could then add extensions, like #retrieveContents. After the separation I would like to extend ZnUrl to at least support file URIs (file://) since these are very useful. I am not sure that extending ZnUrl to be more general and to satisfy all users will be easy, I fear some conflicting goals, but we'll see. The end goal is of course to replace the old classes and simply Pharo. Any comments ? Sven PS: Of course, there would be a unit tests package as well. Actually, any changes should be test driven. -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill
On Dec 7, 2012, at 8:47 PM, Sven Van Caekenberghe wrote:
Hi,
This is request for comment on an idea, as suggested by Pavel because he needs it for his kernel building/packaging work, but also in line with several existing issues related to URL, URI and mime types.
The idea would be to create a new package called 'Zinc-Resources' or maybe 'Zinc-Resource-Description' to contain just ZnUrl and ZnMimeType (and their supporting clases if any). The packaging requirement would be that the new package can only depend on core Smalltalk and not on any IO related packages such as File, Network or HTTP (Zn). Afterwards, File, Network or HTTP (Zn) could then add extensions, like #retrieveContents.
After the separation I would like to extend ZnUrl to at least support file URIs (file://) since these are very useful. I am not sure that extending ZnUrl to be more general and to satisfy all users will be easy, I fear some conflicting goals, but we'll see.
I would really like to have one good URL/URI class and I like the idea proposed by pavel/you!
The end goal is of course to replace the old classes and simply Pharo.
Any comments ?
Sven
PS: Of course, there would be a unit tests package as well. Actually, any changes should be test driven.
-- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill
On 7 December 2012 20:47, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Hi,
This is request for comment on an idea, as suggested by Pavel because he needs it for his kernel building/packaging work, but also in line with several existing issues related to URL, URI and mime types.
The idea would be to create a new package called 'Zinc-Resources' or maybe 'Zinc-Resource-Description' to contain just ZnUrl and ZnMimeType (and their supporting clases if any). The packaging requirement would be that the new package can only depend on core Smalltalk and not on any IO related packages such as File, Network or HTTP (Zn). Afterwards, File, Network or HTTP (Zn) could then add extensions, like #retrieveContents.
After the separation I would like to extend ZnUrl to at least support file URIs (file://) since these are very useful. I am not sure that extending ZnUrl to be more general and to satisfy all users will be easy, I fear some conflicting goals, but we'll see.
The end goal is of course to replace the old classes and simply Pharo.
Any comments ?
No comments. Do it. :) yeah. we could have a simple registry for schema handlers and for mime handlers.. so, other packages can add own handlers to either of them. as result, no tight coupling.
Sven
PS: Of course, there would be a unit tests package as well. Actually, any changes should be test driven.
-- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill
-- Best regards, Igor Stasenko.
participants (3)
-
Igor Stasenko -
Stéphane Ducasse -
Sven Van Caekenberghe