New Castle.IO project?

[Henrik Feldt]

Hello everybody,

 

I’m merging open file system and fluent path into what was Castle.Transactions for the transactional file systems’ benefit.

 

But it’s not so smooth to have it coupled to the transactional behavior – one would have to know both projects to change one, and the IO project is becoming large.

 

Can we create a new project Castle.IO?

 

This would also involve Sebastien Lambla and Bertrand Le Roy who are the authors of openfilesystem and FluentPath respectively – it would be great if they would be allowed to push to this specific repository. I generally think it’s a good thing to work together with other OSS projects and cooperate with them, which is why I’m not re-doing their work but asking them to work with me.

 

What do you think?

 

Cheers,

Henrik

 

PS, features for this project:

 

* Transactional file system

* Non-transactional file systems on Windows

* Same for *nix-systems

* A fluent API for these systems through both interfaces and extension methods on these interfaces

* Long path support (no more >245 chars exceptions)

[John Simons]

>Long path support (no more >245 chars exceptions)

I'm sold :)

Which API supports this?

[Cristian Prieto]

The operating system (in Windows NT) supports long path natively, sadly the .net framework developers used the "old" API with no long path support.

A good set of articles around that are:

http://blogs.msdn.com/b/bclteam/archive/2007/02/13/long-paths-in-net-part-1-of-3-kim-hamilton.aspx

http://blogs.msdn.com/bclteam/archive/2007/03/26/long-paths-in-net-part-2-of-3-long-path-workarounds-kim-hamilton.aspx

http://blogs.msdn.com/bclteam/archive/2008/07/07/long-paths-in-net-part-3-of-3-redux-kim-hamilton.aspx

Cheers,

Cristian Prieto

--
You received this message because you are subscribed to the Google Groups "Castle Project Development List" group.

To view this discussion on the web visit https://groups.google.com/d/msg/castle-project-devel/-/uNdWW07LKfUJ.

To post to this group, send email to castle-pro...@googlegroups.com.
To unsubscribe from this group, send email to castle-project-d...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/castle-project-devel?hl=en.

[Sebastien Lambla]

+1 but I’m stuck with OpenFileSystem as a namespace / name, openwrap 1.0 depends on it and the shell doesn’t auto-update, changing names would break my installed based which is not ideal.

 

From: Bertrand Le Roy [mailto:Bertran...@microsoft.com]
Sent: 28 September 2011 22:55
To: Henrik Feldt; castle-pro...@googlegroups.com; Sebastien Lambla
Subject: RE: New Castle.IO project?

 

+1 obviously J

[G. Richard Bellamy]

Sebastian,

So, you've got a hard dependency on the OpenFileSystem namespace because you've got deployed o.exe users, and o.exe doesn't autoupdate?

Am I missing something here? If they're 1.0 users, then won't they just retain the assemblies used by o.exe, and when they upgrade, couldn't you change the dependency tree? Isn't this equivalent to removing an old, and then adding a new dependency?

-rb

--

You received this message because you are subscribed to the Google Groups "Castle Project Development List" group.

[Sebastien Lambla]

Well no because o.exe is separate from everything else, we’ve had issues before because of that. It’s all rather complicated.

 

What I discussed with Henrik was to migrate to a common codebase while preserving some of the existing assemblies and namespaces on my side, using some sort of templating. I’m gonna have to re-review those plans end of next week so maybe I’ll find a better way to solve this.

[Henrik Feldt]

What does hammett think? Green light?

[Hamilton Verissimo de Oliveira]

Go for it

Sent from my Windows Phone

---

From: Henrik Feldt
Sent: 9/29/2011 12:45 PM
To: castle-pro...@googlegroups.com

[Henrik Feldt]

@hammett:

 

But you are not backtracking from this thread. It’s a new project, by majority vote. So castle is *the* vehicle.

 

Cheers,

Henrik

[hammett]

http://www.castleproject.org/community/bylaws.html

I veto it.

--
Cheers,
hammett
http://hammett.castleproject.org/

[Henrik Feldt]

However, we can discuss whether it should be in a *git repository* on the top level, as long as it’s marketed well. If it’s more convenient to have it in a non-top level repository in terms of building (the reason for the whole discussion), I can place it in the Castle.Transactions repo without a problem!

[Henrik Feldt]

That is; I’m not after having x number of top-level repositories that I write code for – I’m after having users use our code and enjoying the use of it.

[Henrik]

Do you still do that if it's a part of another *git repository* like I
suggested in my last e-mail?

Also, remember this:
"Vetos with no explanation are void"

> > From: G. Richard Bellamy [mailto:rbell...@pteradigm.com]
> > Sent: 29 September 2011 14:51
> > To: castle-pro...@googlegroups.com
> > Cc: Sebastien Lambla; Bertrand Le Roy; Henrik Feldt
> > Subject: Re: New Castle.IO project?
>
> > Sebastian,
>
> > So, you've got a hard dependency on the OpenFileSystem namespace because
> > you've got deployed o.exe users, and o.exe doesn't autoupdate?
>
> > Am I missing something here? If they're 1.0 users, then won't they just
> > retain the assemblies used by o.exe, and when they upgrade, couldn't you
> > change the dependency tree? Isn't this equivalent to removing an old, and
> > then adding a new dependency?
>
> > -rb
>
> > On 9/29/2011 5:46 AM, Sebastien Lambla wrote:
>
> > +1 but I’m stuck with OpenFileSystem as a namespace / name, openwrap 1.0
> > depends on it and the shell doesn’t auto-update, changing names would break
> > my installed based which is not ideal.
>

[hammett]

As long as another repository is under /castleproject and abide to its rules.

The explanation for the veto is the whole other thread. I dont see you
making your concerns clear, instead you confront/attack. My time is
too precious to waste on these energy draining activities. It's not
the first time it happens with you and I'm sure it wont be the last.
Like I said before, if you want full control over your projects, move
it somewhere else.

[Henrik]

OK, awesome then.

I'm happy where I am thank you.

> > For more options, visit this group athttp://groups.google.com/group/castle-project-devel?hl=en.
>
> --
> Cheers,
> hammetthttp://hammett.castleproject.org/

[Henrik Feldt]

I'm aware that I may be interpreted that way. You must understand that this
is not my intention... I will try to formulate my concerns more clearly
before disagreeing in the future. Since I know that I might be taken this
way I often suggest a phone call/skype instead, because when I have those I
don't sound as confrontational.

At least I end it with;
Cheers, ;)
Henrik

>> > +openwrap 1.0

[hammett]

What was the conclusion of this whole discussion? What should be done
with the repositories?

[Henrik Feldt]

Put C.Tx back into its own repo, castleproject/Castle.Transactions, because
it's a top-level project.

castleproejct/Castle.Transactions will contain a working tree of Castle.IO
at tags of releases. Castle.IO sub-level project.

[Krzysztof Koźmic]

I can still see Tx stuff in Windsor repository.
https://github.com/castleproject/Windsor

Is that intentional?

Krzysztof

[hammett]

i havent had the time to change anything. And i'm still unsure of the changes..

2011/11/1 Krzysztof Koźmic <krzyszto...@gmail.com>: