« Return to Thread: scalax I/O and Resource Management Fork
Re: scalax I/O and Resource Management Fork
by Jesse Eichar-2
::
Rate this Message:
THANK YOU!
Scala's IO is currently one of the biggest weaknesses for me. I have
slowly been evolving a little scalax-like library to handle this sort
of thing as well ( against my wishes since scalax has not seemed very
healthy as of late.)
Please let me know when I can begin testing. I am watching the repo
already and am excited to see what come from it.
A quick word to consider. In my use cases one of the biggest wins
have been handling tree's of files/directories. I requested and
helped introduce the Walker/FileTree to scalax.io and have privately
extended it so that there is more control for how directory trees can
be traversed.
The next big pluses are being able to easily read and write to files
without so much overhead of creating Readers/Writers, Channels etc...
Do you have any design ideas yet? Maybe consider looking at the
design of the nnio that is coming in Java 7 for some inspiration (I
havent but seems like it might be a good idea).
My 2 cents,
Let me know if you want any design/code reviews/testing. (This is
near and dear to my heart)
Jesse
On Sat, Jun 20, 2009 at 9:01 PM, Josh Suereth<joshua.suereth@...> wrote:
> Hi Scalax-ers,
>
> This is Josh Suereth and Erik Engbrecht. The BEAST has decided to improve
> Scala's I/O libraries as part of our contributions to Scala. We were
> thinking we could take the Resource Management portions and I/O from scalax
> and try to evolve it independently (and under the same BSD license). Our
> reasoning behind this is to minimize the scope of the project (mainly to
> good I/O in scala). We believe that we can take the existing (and rather
> nice) scalax libraries and provide documentation/final touches. We would
> also use SBT's new multi-scala-version release mechanism to promote this
> subset of scalax. This way the library can easily be used across multiple
> versions of Scala. We feel better support across Scala versions is critical
> to future commercial adoption, especially in larger, more conservative
> settings.
>
> We don't want to split the community. We believe a narrower focus will help
> us deliver a finished product in a shorter timeline. We will keep a
> compatabile license with the end goal being merge back into scalax and
> hopefully scala itself. We're calling the project scalax.io, and it's
> located on github. We'd like to keep the community active and involved and
> invite all current members to contribute to the project. We plan to have a
> 0.1 (complete with documentation) released in 2-3 months.
>
>
> - The BEAST
>
Scala's IO is currently one of the biggest weaknesses for me. I have
slowly been evolving a little scalax-like library to handle this sort
of thing as well ( against my wishes since scalax has not seemed very
healthy as of late.)
Please let me know when I can begin testing. I am watching the repo
already and am excited to see what come from it.
A quick word to consider. In my use cases one of the biggest wins
have been handling tree's of files/directories. I requested and
helped introduce the Walker/FileTree to scalax.io and have privately
extended it so that there is more control for how directory trees can
be traversed.
The next big pluses are being able to easily read and write to files
without so much overhead of creating Readers/Writers, Channels etc...
Do you have any design ideas yet? Maybe consider looking at the
design of the nnio that is coming in Java 7 for some inspiration (I
havent but seems like it might be a good idea).
My 2 cents,
Let me know if you want any design/code reviews/testing. (This is
near and dear to my heart)
Jesse
On Sat, Jun 20, 2009 at 9:01 PM, Josh Suereth<joshua.suereth@...> wrote:
> Hi Scalax-ers,
>
> This is Josh Suereth and Erik Engbrecht. The BEAST has decided to improve
> Scala's I/O libraries as part of our contributions to Scala. We were
> thinking we could take the Resource Management portions and I/O from scalax
> and try to evolve it independently (and under the same BSD license). Our
> reasoning behind this is to minimize the scope of the project (mainly to
> good I/O in scala). We believe that we can take the existing (and rather
> nice) scalax libraries and provide documentation/final touches. We would
> also use SBT's new multi-scala-version release mechanism to promote this
> subset of scalax. This way the library can easily be used across multiple
> versions of Scala. We feel better support across Scala versions is critical
> to future commercial adoption, especially in larger, more conservative
> settings.
>
> We don't want to split the community. We believe a narrower focus will help
> us deliver a finished product in a shorter timeline. We will keep a
> compatabile license with the end goal being merge back into scalax and
> hopefully scala itself. We're calling the project scalax.io, and it's
> located on github. We'd like to keep the community active and involved and
> invite all current members to contribute to the project. We plan to have a
> 0.1 (complete with documentation) released in 2-3 months.
>
>
> - The BEAST
>
« Return to Thread: scalax I/O and Resource Management Fork
| Free embeddable forum powered by Nabble | Forum Help |
