Re: [e4-dev] Introduction #2

[John Arthorne <John_Arthorne@xxxxxxxxxx>]

Hi Andrey, welcome to e4. It sounds
like you are doing interesting work and I look forward to hearing more
about your progress. I just have one small question from the long list
of points in your email. Can you describe more what you mean by this:

> It is based on "stale deltas" event notification
approach (notifications do not guarantee anything about the state of >
the model, thus assuming notification layer of all dependent models to
be isolated from the model-building layer), 

Do you mean the resource deltas are
stale because they don't represent the current state of the underlying
file system? I'm not sure how we can improve on this given that other processes
can be modifying the file system at any time.  Resource deltas on
the other hand do describe exactly the current state of our in-memory model
of the workspace. The workspace is locked during notification, and the
delta is computed based on the current state as computed after locking
the tree. Can you clarify the problem you see here?

Thanks,
John

"Andrey Tarantsov" <andreyvit@xxxxxxxxx>
Sent by: e4-dev-bounces@xxxxxxxxxxx

11/16/2008 05:07 PM

Please respond to
E4 Project developer mailing list <e4-dev@xxxxxxxxxxx>

To	"E4 Project developer mailing list" <e4-dev@xxxxxxxxxxx>
cc
Subject	[e4-dev] Introduction #2

Hi, everyone,

I thought that I could introduce myself, given that I've
started posting to this list.

I'm a former (initial) contributor of Eclipse Dynamic
Languages Toolkit project. Now I co-founded an IDE-oriented company, and,
while living from consulting, we're using all internal resources to work
on a set of IDEs for dynamically-typed languages. We're a small company
trying to do a very big task, so we may fail mid-way, who knows.

Our effort is in many things similar to what you guys
are doing. We've started with reusing Eclipse stuff, but quickly found
that it is of unacceptable quality (according to our standards and understanding).
I know this point of view will be regarded highly controversial here, and
that's the main reason why we never thought about being involved in e4.

However now I think that maybe it would be good for both
sides to at least share ideas and understanding of requirements.

What I think sucks most about Eclipse 3.x is usability.
Tons of options. UI not focused on user tasks and not speaking in user's
terms. Extremely low visibility of commands. Lots of unneeded modality.
I know it can be used (I'm an active user of Eclipse myself for many years),
but I know an IDE can be a lot better than that.

What I thinks sucks second-to-most about Eclipse 3.x is
reliability. "User operation blocked by background task" not
allowing me to save stuff when seemingly unrelated background jobs are
running. All those friking resource-out-of-syncs, especially during CVS
operations. 

As one example of internal problems causing lack of reliability,
I believe Eclipse Resource Model has completely "untrustworthy"
semantics. It is free threaded and does not provide transactional semantics.
It is based on "stale deltas" event notification approach (notifications
do not guarantee anything about the state of the model, thus assuming notification
layer of all dependent models to be isolated from the model-building layer),
which pushes the same semantics on all dependent models (see delta processor
monster in JDT). It's hard to write code using the resource model and say
that it obviously works (which is the only way to write good code IMO).
The "obviously works" part disappears in face of the fact that
you know nothing about the state of the resource model, and you never have
a consistent (non-controversial) state at your disposal.

We are working on a resource model which provides a persistent
global undo (preserved across restarts) and transactional semantics on
a subset of workspace files. We kinda made a compromise between being able
to open any remote filesystems as native IDE projects and having everything
available locally by defining strict rules of what gets eagerly syncronized
with a local cache when opening a remote project. (In a modern IDE there
will surely be someone willing to read and index all files, so such a compomise
is a useful way to limit indexing/building activities to a predictable
set of files.)

Again, given that noone would want to break compatibility
(though I thought that it should be possible to emulate e3 behaviour based
on better transactional models) and most people do not consider e3 problems
to be too significant, I'm not expecting to push any of our ideas here.
Instead I'm expecting to periodically remind everyone to consider possible
usability issues and make informed decisions (...here we're sacrificing
usability because of backward compatibility, there we're sacrificing usability
because it's so fun to generalize all web projects into a single concept,
and now we're sacrificing usability because we love adding configuration
options...)

Contributing something we all agree on is another possibility,
if we ever agree on something. I'm not a big fan of EMF (as I believe in
rich models and "Tell, Don't Ask", so don't see a big need in
fancy data structures) etc.


BTW, has anyone formulated the high-level goals of e4
project? What are you (we) trying to accomplish? Whom are we trying to
help? Which problems to solve? One goal I know about is to make Eclipse
applications accessible via web browser. (But again, who will be using
this feature? To solve which problems? It usually helps to know the answers
to these questions when designing things.)

Sorry if I'm bringing up something you have already discussed
and settled.

-- 
Andrey._______________________________________________
e4-dev mailing list
e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/e4-dev