I think WO is the best tool but EO is not for everyone.
I would agree with this ... EOF is excellent, but there are aspects
that I wish were more configurable. That said, I have never found a
problem that I couldn't solve.
When I try to find developers for WO other than me,it was difficult
or high cost.
People who can select to learn WO or EO is very limited.This is
contrast to PHP.
Yes, there are a huge number of PHP developers. If you find a WO/EO
person, they are likely to be a lot more expensive (and harder to find
in the first place), but if you do, they are likely self-selected to
be a much better quality developer on average. We don't hire WO
people. We hire good developers and we train them on WO. Honestly
this would be true of almost any organization. Most companies use a
mix of technologies and you rarely find someone who can just roll in
off the street and work on your system. There is always a training
investment.
So I am afraid that using EO may not be the best solution.
I'm not sure I would necessarily conclude this ... This same argument
could equally be made for the "WO" part of WO/EOF, right?
(I have a mac but it is not my main machine. so I will never upgrade
WO from 5.2)
Not sure why you wouldn't go to 5.3, but I suppose you have your
reasons.
Don't you think terracotta's approach can enhance WO significantly
with or without EO?
Without EOF .... possibly. With EOF, it's a very complicated problem
because EOF is single-lock on an object store. The contention point
in most WO apps is going to be your EOF lock, so clustering that lock
is only going to INCREASE contention. The typical WO scaling approach
is multiple instance, though as you see, this presents cache sync
issues (which is why ERJGroups exists).
I think Tools of WO and structures are still the best but EO is not
the best today.
I think it is just different. It's difficult to flat out say it's not
the best. You're pretty much going to be comparing against Hibernate,
I think. Hibernate doesn't do in-memory transactions, which I find to
be incredibly powerful. Hibernate, though, supports a richer caching
system which supports a distributed cache and has some SQL
optimizations that EOF doesn't. It doesn't do snapshot caches in
quite the same way, and most people don't really do multi-request
transactions with Hibernate. I'm not necessarily convinced that a WO
+ Hibernate app is a bad idea, just a very different programming
model. You should just be aware of what you're giving up making that
decision.
I think EO's approach is delaying to the latest.
I don't want to use additional mechanism or lock-unlock management
just to increase instances or multiple requests.
If Apple don't replace it and I don't have enough time to learn
wonder I have to replace EO with something.
This is why I use Wonder ... It basically automatically solves most of
these complaints.
I think
1) Having caches for each instance is not efficient. Sharing cache
is the best.
This is VERY application-dependent. It makes some aspects of
development easier and some harder. If you have a large amount of
user-specific data, sharing a cache is just a good way to blow out
your cache. If you have very collaborative data, then a central cache
would probably be better. But shared caches aren't free ... The more
people you have using your cache, the more you are going to have to
lock, and if you're not locking, then you have to deal with the
fallout of not having a safe transaction model (unless you're using a
cache that is safely hooking into your overall transaction system and
does something like mvcc).
2) Developers today have to learn many things so learning vendor-
closed technology is not for everyone.
I would agree with this ..
3) EOF may use String and Hashtable for many internal processes.This
may slow the app.
I'm not sure what you mean about this one, but maybe you mean as
opposed to storing persistent object state in the fields of the pojo?
I think you'll find that if you profile your app, it's hitting your
database that is slow by a huge margin. Switching from state-in-maps
vs state-in-fields is likely not really near the top of the list.
So, really I don't think you're wrong, you just have to accept that
there aren't many people doing things like you are talking about
taking on, so you need to weigh that risk. But as long as you're OK
with that, I don't really see any terrible problems waiting for you.
I've considered making a WO + Hibernate app just to try it out, also.
ms
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
