Planning NH next
Fabio Maulo
Fabio Maulo
Frans Bouma
otherwise it's just a point release. I wouldn't go for 4.0 with just 1
change, that should be a point release (e.g. 3.1). As the assembly is
signed, people have to manually upgrade from 3.0 to 3.1 anyway, so it's not
as if people will run into big problems when installing 3.1 next to 3.0
For 4.0, as I've said in the NHusers list before (but I got ripped apart
because of it), what's really needed is a turn-key package, so when someone
downloads NHibernate, everything is in there, and the developer can just
turn things on or off through configuration. No more hunting down contribs
from all over the place, which have mismatching dependencies (e.g. what was
the case with FNH 1.0 for example), just 1 package, 1 source for the goods,
and nothing else.
The longer you wait, the harder it will be to get new users in and keep
existing users on-board. In todays world, developers don't want to spend
hours looking for libraries supporting their NH code, if a competing o/r
mapper has everything in 1 box: time is money.
Another, IMHO major, point is that it should be forbidden to post a blogpost
about a new feature unless the new feature is also properly documented with
official docs. The current docs are outdated, and it's a massive job to get
it up to par, but the longer you wait, the bigger this gap will become, and
it will again turn into a situation where a developer has to hunt down
blogposts for documentation about that specific feature or setting.
If NH takes itself serious and as a professional framework, it should get
itself together and promote itself as one: proper, up to date docs, proper
one-stop download site and configuration so getting started and getting up
and running with all cilinders running is easy and quick.
I know this all will take a lot of time, but IMHO it's time well spend, at
least better spend than on some edge case feature only 3 people will ever
use or yet another way to query your domain.
FB
Valeriu Caraulean
Hi team.
Valeriu Caraulean
Pablo Ruiz
Diego Mijelshon
4. On top of this, we really need to do something about documentation. There are lots of things that are only documented in blogs (all of LINQ, for example), and many outdated examples and java-isms. I can try to take charge of this myself, but I need a little help getting started. If anybody wants to start working with me in this, I have some free time on weekdays before 14 and after 23 UTC; just send me an email.
Diego
Fabio Maulo
Fabio Maulo
Rory Plaire
Stephen Bohlen
This landscape is significantly fractured right now and from my observations many of these projects are quite dissimilar in re: the problems they are trying to solve and their approach to solving them once you start to dig beneath the surface. I suspect that near-term the term 'package manager' will prove too broad to (properly) describe them all :)
Steve Bohlen
sbo...@gmail.com
http://blog.unhandled-exceptions.com
http://twitter.com/sbohlen
Diego Mijelshon
Diego
Stephen Bohlen
My observation thus far is that most (if not all) of these package manager projects are going to create package descriptors for NH without our needing to lift a finger (at least initially). It would be hard for any package manager attempting to deliver OSS for .NET to claim ubiquity without their having a package descriptor for NH. At least for the time being NH is in the position of being courted by the package management projects rather than the other way around :)
After the landscape settles down a bit and successes and failures emerge from the ashes its probably worth investing the time in trying to maintain 'official package descriptors' for the one or more of these that manage to gain traction in the broader community...unless we find that existing package descriptors are in some way incorrect, defective, resulting in a poor experience for adopters, etc. But for the mean time, the package descriptor formats are in heavy flux, early beta, and other slippery states where trying to chase them all at this point is probably a lot of work with low (relative) ROI.
Diego Mijelshon
Diego
Ayende Rahien
Rory Plaire
Fabio Maulo
Fabio Maulo
Julian
doesn't make anybody happy, it will be consigned to obscurity by
Entity Framework.
>
> >> Hi *team*.
Roy Jacobs
> well... you must be happy with NH3.0.x or you have to find somebody to
> maintain NH3.0 for you.
involves upgrading build systems, developer tools, etc. Furthermore,
you're also forcing all of your customers to upgrade to .NET4.
I agree that NH should move to .NET4, but if there can be at least
some degree of backwards compatibility with .NET3.5, even at the cost
of a reduced featureset, that would be very beneficial in terms of
getting people to adopt NH, or to keep them using it.
Roy
Wenig, Stefan
erratum: but right now they are definitely focused on getting LAMP apps running on Windows of course, not Linux.
I.e., they try to package Apache, PHP and Python so that applications can use these prerequisites.
From: nhibernate-...@googlegroups.com [mailto:nhibernate-...@googlegroups.com]
On Behalf Of Wenig, Stefan
Sent: Thursday, October 14, 2010 12:35 PM
To: nhibernate-...@googlegroups.com
Subject: RE: [nhibernate-development] Planning NH next
Hi
I love CoApp, but right now they are definitely focused on getting LAMP apps running on Linux. They want to release next spring, and only then they’ll start looking into installing .NET apps.
Also, while building, installing and updating libraries is a big-time goal for them, it’s more in the context of application prerequisites, not installing libs on a dev machine.
Don’t get me wrong, I love the vision of CoApp, but it’s not there yet and it really serves a different purpose. (Garret said they are looking at integrating NuPack code in CoApp. We’ll see.)
You’ll eventually want NH packages to be available so that NH-based applications can install with CoApp. If you also want to support build from source and updating, there’s probably a lot of work to do for both the CoApp project and the packager.
NuPack will come with VS. It solves a simple problem: it just installs binaries and configures your VS project. So it might look less ambitious than horn & co, but ambition comes at a price: that stuff just doesn’t work. With NuPack, building is the packager’s problem. (However, I’d like to know what NuPack does when, say, two libraries come with different versions of the same dependency, such as Castle…)
CoApp is really fascinating, while NuPack looks like a marketing tool (gallery) + automation of a few simple steps. Still, if you want my advice:
· Make official packages for NuPack, because it is easy and will have impact.
· Let others like OpenWrap handle NH themselves. (OpenWrap announced it will support NuPack format, btw)
· Just wait and see where CoApp goes.
Hope this helps,
Stefan
Wenig, Stefan
Hi
I love CoApp, but right now they are definitely focused on getting LAMP apps running on Linux. They want to release next spring, and only then they’ll start looking into installing .NET apps.
Also, while building, installing and updating libraries is a big-time goal for them, it’s more in the context of application prerequisites, not installing libs on a dev machine.
Don’t get me wrong, I love the vision of CoApp, but it’s not there yet and it really serves a different purpose. (Garret said they are looking at integrating NuPack code in CoApp. We’ll see.)
You’ll eventually want NH packages to be available so that NH-based applications can install with CoApp. If you also want to support build from source and updating, there’s probably a lot of work to do for both the CoApp project and the packager.
NuPack will come with VS. It solves a simple problem: it just installs binaries and configures your VS project. So it might look less ambitious than horn & co, but ambition comes at a price: that stuff just doesn’t work. With NuPack, building is the packager’s problem. (However, I’d like to know what NuPack does when, say, two libraries come with different versions of the same dependency, such as Castle…)
CoApp is really fascinating, while NuPack looks like a marketing tool (gallery) + automation of a few simple steps. Still, if you want my advice:
· Make official packages for NuPack, because it is easy and will have impact.
· Let others like OpenWrap handle NH themselves. (OpenWrap announced it will support NuPack format, btw)
· Just wait and see where CoApp goes.
Hope this helps,
Stefan
From: nhibernate-...@googlegroups.com [mailto:nhibernate-...@googlegroups.com]
On Behalf Of Rory Plaire
Sent: Thursday, October 14, 2010 1:17 AM
To: nhibernate-...@googlegroups.com
Subject: Re: [nhibernate-development] Planning NH next
Ayende -
Fabio Maulo
(running on .net4)
--
Fabio Maulo
Stephen Bohlen
Having a hard requirement on .NET 4 is empowering for the project's (potential) capabilities, but is likely to be limiting in its potential adoption -- at least for a while.
My own prediction (remains to be seen, of course) is that the present (and immediate future) financial climate in the global economy will make the adoption-curve of .NET 4 a lot flatter than the adoption of .NET 2 was (meaning that taking a hard dependency on .NET 4 is likely to be adoption-limiting for a longer period of time than it had been for just about any prior .NET upgrade cycle).
Based on what I'm hearing out there, very few people are looking longingly at .NET 4 and saying "I have to have that in my company immediately" and I'm skeptical that EF4, MVC3, and a few other MS technologies that are .NET 4-only will (quickly) change their minds.
Though the next obvious question is "how many of these stuck-in-the-mud, trapped-in-the-past enterprises are even candidates for adopting something like NH in the first place?"
All that said, as a non-commercial software project, adoption is merely one of many metrics NH can chase, so I think a choice either way is entirely defensible.
My two cents.
-Steve B.
>> produce 3.5 assemblies (VS2010 finally has_real_ multitargeting). Maybe we
>> - The differences between .NET 3.5 and .NET 4.0 are limited to a couple
>> files that might reference ISet<T> (unless we start messing with dynamic and
>> things like that).
>>
>> That's for the technical side...
Fabio Maulo
Fabio Maulo
Johannes Gustafsson
Valeriu Caraulean
Diego Mijelshon
Diego
Julian Maughan
line, nevermind for two.
Julian Maughan
be maintained.
...but the point is that we don't *have* to go to .NET 4. We can stay
(for now) on .NET 3.5 which, as Stephen points out, actually gives NH
an advantage over EF4. And we don't have two code lines hurting
productivity.
Replacing the Iesi ISet implementation doesn't seem like a strong
enough reason to move framework. What are the other benefits of moving
to .NET 4 now (or soon)?
I'm not suggesting we never move to .NET 4; just questioning the
timing. Plus take a look at the issues Frans raised (at the start of
this thread). There are actually some very basic things that NH is not
doing right, before we start move onto 'the next big thing'. For
NHibernate to be taken seriously it really need to be presented much
better - like the serious, capable, enterprise-ready product it is,
rather than a hobby-shop project.
Diego Mijelshon
Diego
Frans Bouma
> branch targeting .NET 3.5 and 4.x targeting .NET 4.0.
I don't see that. IMHO the consensus is that focusing on .NET 4.0
will limit adaption for that version, unless .net 4 is used everywhere,
which I don't see happening soon (I agree with the description Bohlen gave)
> That does imply a bit of additional work (backporting patches), but it
keeps
> things simple enough. A guideline for submitted patches should be
> established, so the contributors do the work themselves when fixing bugs,
> instead of deferring everything to the committers.
> We could then establish a threshold of .NET 4.0 adoption that will result
in
> killing the 3.x branch, like 90% (I have no idea how to measure it, but
I'm
> wearing my free brainstorming hat at the moment. Maybe downloads/month)
Remember that killing a branch or 'leaving it up to the user to
patch things' won't help the acceptance rate among enterprises and large
teams: they don't want to spend time (and thus money) on poking into a
codebase they're not familiar with to get data in/out of a database.
FB
Wenig, Stefan
Cheers,
Stefan
Julian Maughan
make happy?"...but perhaps it was too subtle :)
>
> read more »
Frans Bouma
Just my 2 cents (also from the outside! ;)): if you don't start seeing NH as
a professional system which cares about users and strives for being seen and
act as a professional toolkit (that's not equal to being a 'mature'
library), decline in usage numbers will, over time, be the end result,
simply because alternatives become more mature and the gap between NH and
alternatives will become smaller if not non-existent.
I.o.w.: you shouldn't hide behind the 'but it's OSS so we can't get to the
level of professionalism commercial / MS can deliver' anymore.
again, just my 2cts, do with it what you want.
FB
Wenig, Stefan
There's a constant flow of arguments here that more or less says that there's no reason to. You build whatever you think makes sense, and if users don't like that, too bad. NH will not fall into obscurity any time soon, so do you care?
Diego Mijelshon
Diego
Fabio Maulo
Do you really think that 100000 downsloads of NH2.1.2 binaries are
because a lot of students likes NH for their school tasks ?
--
Fabio Maulo
Frans Bouma
> Do you really think that 100000 downsloads of NH2.1.2 binaries are because
a
> lot of students likes NH for their school tasks ?
read my 1st reply in this thread. You asked a question, I gave my
input. You don't have to use it. To rehash:
- proper docs which are up to date
- decent supported codebase, so you aren't left in the code right after
release because a new version is started
- all functionality needed in 1 box, so you can focus on what you're payed
to do.
FB
Fabio Maulo
- all functionality needed in 1 box, so you can focus on what you're payedto do.
Fabio Maulo
Frans Bouma
I posted questioned on twitter. if you have questions, ask them in a reply
2nd: I meant: if I want for example:
- auditing,
- validation
- INotifyPropertyChanged
- security
in my application which uses NH, I'd like to do that with e.g. configuration
elements in the config file, and not having to worry whether I have the
latest nightly build of a 0.x versioned lib tucked away in some dark corner
of sourceforge: that's bad because:
1) what if the lib gets abandoned in a year? Will I still be able to
maintain my app?
2) what happens if I update NH because of a bugfix release?
FB
Fabio Maulo
Fabio Maulo
Frans Bouma
level, however they're all services which build on top of the O/R mapper
core and utilize it, which also means that if you use NHibernate, and you
want to use the features I mentioned, you need to implement them somehow so
they utilize NHibernate.
That initially takes time, which shouldn't be necessary.
> - auditing <= outside NH scope. There are various interpretations of what
> mean "auditing". In the NH3 cookbook you have 3 solutions without need to
> add external references. Simon and Roger are working on the port of Envers
> that is another interpretation about what mean "auditing".
to track which user read / wrote which property, you need to emit
code in the proxies, there's no way around that. If you want to auto-persist
audit info in entities when the transaction commits, you need to write
interceptors (IIRC). I'm sure it's already been done a couple of times, but
that's not the point. The point is: the user now has to hunt down where to
get the auditing functionality so it's added to the complete stack of
persisting and reading entities.
> - validation <= outside NH scope and, btw, you have at least others 4
> frameworks we the specific responsibility of validate objects.
> DataAnnotations, VAB, Castle, Spring, FluentValidation and so on.
Validation
> is a cross cutting concern, NH give you the ability to inject the
validation
> of your objects before persist it (on Save, update.... or just before
flush
> the session).
Same thing as auditing: it's been done before, but what if someone
wants to enable it, e.g. enable field level validation with IDataErrorInfo
without having to write endless piles of code? Or auto string/bytearray
length checks based on mapping info, or decimal precision/scale checks?
That's stuff that's 'very handy to have', and should be enableable through a
setting, not by hunting down code which might be outdated.
> - INotifyPropertyChanged <= I have no idea about what mean to give support
> to INotifyPropertyChanged. NH is not a code-generator to generate
entities.
> If your entities implements INotifyPropertyChanged for NH there is no
> problem. If, in your opinion, you can take some advantage implementing
> INotifyPropertyChanged you can do it with less than 50 code lines:
> http://fabiomaulo.blogspot.com/2010/10/turbo-nhibernate-with-domain-
> invaders.html
I was refering to auto emitting the interface in the proxies. You
refer to a blogpost, which proves my point.
> - security <= I'm inclined to say that again it is outside NH scope but I
> would understand which kind of "security" you are talking about.
yes, security on the persistence level.
Additionally, if someone wants to 2-way bind entities in an asp.net
page with a datasourcecontrol, is that available? I'm sure someone has
written it, but where is it? Things like that make developing code _easier_.
'less friction' is a term I have heard often, well, this is a big friction
releaving thing.
Diego Mijelshon
Diego
pvginkel
was wondering what the advantage would be of using .NET4? I can't
think how dynamic would really help NHibernate, and, is there much
else that could be of use?
Frans Bouma
believe how stupid and shortsighted this is. Fabio, do you really think I
know jack shit about building and releasing software, what O/R mapper using
people need?
On NHUsers some french **** insulted me deeply and mr. Maulo just said
nothing, as if he approved. Here, he asks a question, I answer, try to help
out, and from all the answers, mr. Maulo finds it necessary to mock my
answers on twitter, as if I'm an overpayed consultant living in MS Word all
day. I'm not expecting anyone to agree with me, but I don't expect from
professional developers who debate a serious topic to make fun of my
answers. Why, Maulo? Felt threatened? You think I'm stupid and you want
confirmation from others?
Now let's get back to Diego's reply, which is honest and decent (see, mr.
Maulo? You can also simply debate about technical points of view, and learn
from it perhaps.)
> All the features you mentioned are definitely outside the bounds of NH
> _core_ That doesn't stop people from creating higher level projects like
> Sharp Architecture, which include ready-to-go stacks.
> In fact, they don't even have to be F/OSS: LGPL allows you to include
> NHibernate as part of a commercial tool/framework that does that and more.
I'm not arguing they should be part of the core. That's why I some
time ago said on NHusers, in another endless stupid debate with mr. Maulo
and said french ****, that you have core O/R mapping and entity services. A
couple of years ago we had a meeting between 5-6 O/R mapper developers on a
conference, and debated what direction O/R mapping would go, what things
people would be interested in, just software devs talking tech, not
marketing. We all agreed that the core O/R mapping problem was solved and
done with, but to use it in today's software applications, you need services
on top of that, or better: developers will build functionality on top of the
O/R mapping core, utilizing that core and even wanting to integrate with it,
like validation, security on the db level, auditing, concurrency control,
subclass/proxy functionality etc. etc. It's key for these functionality
elements that they work well with the O/R mapper of choice and work
seamlessly.
It's therefore key to see 'using NHibernate' equal to 'using
NHibernate as O/R mapper core and additional NHibernate targeting services'.
Because, they're tied together: you can't use LLBLGen Pro's
auditing/authorization system which is integrated in our core with
NHibernate's and vice versa.
So it's not about a question whether there IS functionality out
there, I'm sure it's all there somewhere, it's that it:
1) has to integrate well with the NH core used by the developer
2) has to be updated when the NH core updates
3) comes in the same package or at least without the necessity of looking
for all the libs out there. I don't mean, in the same NHibernate.dll, but
shipped with it, so when you download NHibernate, you get everything, and
the _developer_ decides what to use.
Sure there are high-level stacks, but often they surpass what the
developer is looking for, i.e., they don't want a top-to-bottom framework
where they have to color in some blanks, they want to 'outsource' some parts
of their architecture to 3rd party libraries: db access to NHibernate,
auditing, validation etc. to nhcontrib stuff etc. and what is picked from
that big box of chocolates could be different for every project, that's the
beauty of it. The point is that it is easy selectable for the developer, so
the developer knows what he's using is up to date, works together and is
right there, so no hunting across an endless stream of
sites/blogposts/defunct sourceforge projects etc.
FB
Fabio Maulo
Fabio Maulo
Petrov Peter
Fabio Maulo
I think Frans Bouma has unbelievable patience. We aren't far from the time when Frans will say "enough is enough" and I fear it will soon stop following this dev group. It will be a loss for the NHibernate project. With his attitude Fabio will force back other people too. For mr. Maulo it's time to reconsider his attitude toward others and his sharp tone.
Fabio Maulo
Frans Bouma
I wrote on Thursday:
"The examples I mentioned are not things you expect on the core O/R mapper
level, however they're all services which build on top of the O/R mapper
core and utilize it, which also means that if you use NHibernate, and you
want to use the features I mentioned, you need to implement them somehow so
they utilize NHibernate."
Google groups link:
http://groups.google.com/group/nhibernate-development/msg/e91d2b8e8bd202bd?h
l=en
I never said it should be part of the core, as those aren't core NH
services. You have apparently no clue whatsoever I was talking about, which
explains your replies.
Anyway, you have a narrow focus on where NH should go to, but you
don't realize that this focus only targets core O/R mapper functionality, a
problem solved years ago already, which means that there's little to nothing
to do in the future except re-inventing wheels, like we see already with yet
another xml / code based mapping system and yet another query system.
IF I'll eventually say "Enough is enough", I'll fork NH and do what
I explained here. But that takes time and I've to look into what it brings
me, compared to the effort to invest.
FB
Fabio Maulo
I think is the right place.
- audit : talking with Simon and Roger and helping with some code
- validation: working in NHibernate.Validator that has very few few
things in common with Hibernate.validator
- INotifyPropertyChange writing a post to demostrate how do the
integration having a little performance advantage in less then 50 code
lines. I'm ignoring any other possible support.
- security: I have asked explication and I'm still waiting
About fork NH: I have invited people to do it more than one time,
after NH3.x we will move to Hg or Git and who want can do it even more
easy.
To resume:
I still waiting the definition of
- NH "look like depends on the direction where the wind comes from"
- "professional toolkit" and why NH can't be defined a "professional
toolkit" already
- "security" what exactly mean for NH
--
Fabio Maulo
Carlos cubas
-Carlos
Practice makes perfect, but if no one is perfect, why practice?
> From: fabio...@gmail.com
> Date: Mon, 18 Oct 2010 12:41:05 -0300
> Subject: Re: [nhibernate-development] Re: Planning NH next
Frans Bouma
> think is the right place.
> - audit : talking with Simon and Roger and helping with some code
> - validation: working in NHibernate.Validator that has very few few things
> in common with Hibernate.validator
> - INotifyPropertyChange writing a post to demostrate how do the
integration
> having a little performance advantage in less then 50 code lines. I'm
> ignoring any other possible support.
> - security: I have asked explication and I'm still waiting
and I've answered. that you won't listen to what I've to say, that's
your problem really...
to recap: security at the entity and field level, e.g. who can read
/ write property X, who can read / write entity INSTANCE Y etc. this can be
done at the db level (rhino security?) but also at the property level in
memory with intercepting code which consults an 'authorizer' which is
injected into the entity. I don't know if that last bit exists for
NHibernate, if it does, it needs to emit code into the proxies, hence my
remark about it being something one would want to use WITH Nhibernate.
You keep on talking about NHibernate core, but that's not the point
of my argument: I'm arguing that the O/R mapping problem has been solved a
long time ago and when someone wants to use 'NHibernate' the whole scope of
features EXPECTED to be covered with 'using NHibernate' is bigger than the
core O/R mapping problem, i.e. NHibernate dll + contrib stuff + all kinds of
other features scattered all over the place in 3rd party libs.
> About fork NH: I have invited people to do it more than one time, after
> NH3.x we will move to Hg or Git and who want can do it even more easy.
IF I fork it, it won't be a private repository nor will it be aimed
at 'just an nh fork like many others'. But we'll see...
> To resume:
> I still waiting the definition of
> - NH "look like depends on the direction where the wind comes from"
Not sure where this out-of-context remark is coming from, but as you
don't answer/reply to my questions/remarks as well, why should I reply to a
remark which isn't 1) in context and 2) it's not even clear who said it and
when.
> - "professional toolkit" and why NH can't be defined a "professional
> toolkit" already
I gave you 'a' definition, do I have to rehash myself every time ?
Anyway, AGAIN: you asked for input, I gave some input. It's up to
YOU to do something with it. However instead of constructively use knowledge
from the O/R mapper field around you, you block everything out, and more
importantly, your fellow team members don't pick it up either.
Now, why don't you tunnel the energy you've invested in picking
apart my reply instead towards your teammembers who haven't come up with a
list of ideas for 'vNext' ?
FB
Fabio Maulo
Fabio Maulo
Fabio Maulo
Fabio Maulo