Ok... I must explain this : "For easy things you have your real-world work" In real-world the most important is: money, money, money. The main rule in your work is : business target first!
In OSS what is important is: do the right thing applying the best pattern you know. Here we must do our best with: program-to-interface not to implementation, IoC, DI, uncoupling etc. etc. Here the "time" is not important. One of my usual answer in OSS is : "take your time and do your best". On Sat, Apr 24, 2010 at 10:23 AM, Fabio Maulo <[email protected]> wrote: > this is not an easy world. For easy things you have your real-world work. > > Having those projects outside the trunk is perhaps the best decision we > ever taken. > Maintain it aligned to the core-trunk is a task of that specific project > team and not an additional task for core-team. > > You are worried only for Spatial but Spatial is simply the less used > project in contrib; > what about NHCH, NHLQ, NHV, NHSR, NHB, NHMA ? > > If you think that you need to have a reference to Spatial inside the core > we are fried. Perhaps you will need an extension point where it isn't there > so far. > > Steve, > How we are managing custom-function in the new Linq-provider ? > > > On Sat, Apr 24, 2010 at 10:01 AM, David Pfeffer <[email protected]>wrote: > >> I am definitely interested. I'm just confused as to why put it in Contrib? >> Any breaking changes in the NH trunk would have to be fixed in Contrib, and >> you're going to always have the mismatch between Contrib and NH trunk. Also >> you have the awkwardness of having to use Spatial dialects, which means you >> can't use any other library that requires its own dialect. >> >> For example, its going to be very difficult to support Linq in Spatial >> without being able to directly reference spatial from the Linq provider, >> which is now in NH itself. Linq as I'm sure you know converts the user's >> input into an expression tree, and the expression tree walker would need >> awareness of Spatial in order to know that calling, say, .STIntersects on a >> GeoAPI object should correlate to a certain sort of query. Spatial doesn't >> seem to be enough of a "separate project" to be put in NHContrib, if you >> want it to work as well as NHibernate itself does. >> >> >> On Sat, Apr 24, 2010 at 8:52 AM, Fabio Maulo <[email protected]>wrote: >> >>> Spatial, as others prjs are part of Contrib and will be part of Contrib. >>> Perhaps it was one of the best decisions took some years ago. >>> If you are really interested in develop it and maintain it multi-RDBMS, >>> let us know. >>> >>> On Fri, Apr 23, 2010 at 9:46 PM, David Pfeffer <[email protected]>wrote: >>> >>>> Who is working on NHibernate Spatial? It appears to have been dormant >>>> for nearly 9 months now. >>>> Why is NHibernate Spatial not part of NHibernate itself, but instead >>>> part of NHContrib? >>>> >>>> I'd be happy to take over working on NHibernate Spatial if it has been >>>> dropped or contribute substantial assistance if there is someone still >>>> actively maintaining it. There's a lot of work left to do, and I'm >>>> using NHibernate Spatial extensively in a project that currently has >>>> an indefinite ending (-- for a startup company, so either it will die >>>> in a year or two or else I'll be doing this for a very long time). For >>>> example, I'd like to see LINQ support for spatial as well as proper >>>> support for the SQL Server coordinate ordering format. (The latter >>>> being a huge pain point for me.) >>>> >>>> I haven't worked on large open source project in about 5 years now, >>>> but the last time I did I found it to be very rewarding. Considering >>>> in this instance it makes a lot of sense for my start-up for me to >>>> actively see NHibernate Spatial get developed, and it could be fun, it >>>> seems win-win. >>>> >>>> Thanks, >>>> David >>>> >>>> >>>> -- >>>> Subscription settings: >>>> http://groups.google.com/group/nhibernate-development/subscribe?hl=en >>>> >>> >>> >>> >>> -- >>> Fabio Maulo >>> >>> >> > > > -- > Fabio Maulo > > -- Fabio Maulo
