[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [technology-pmc] Sapphire
|
Hi Gunnar,
Thanks for your comments.
> For example, this is too generic:
>
> > This project will be focused on identifying ways to significantly
> > speed up UI development while simultaneously improving quality,
> > maintainability and consistency.
>
> It basically opens the project to *anything* UI development related.
This sentence is meant as an introduction to scope, with the rest of the
scope section clarifying and narrowing it, but if you have specific wording
changes that you think would improve it, please let me know.
> Also the next sentence is too open IMHO.
>
> > Some of the key deliverables:
>
> From reading the proposals it sounds like point 1 and 3 should be *the*
> key deliverables but not _some_.
I can remove the word "some", but it does not make sense to remove #2. It is
key to making Sapphire possible.
> I'd also like you to consider how others can adopt/benefit from
> Sapphire. For example, can you imaging that you (initially) just focus
> on the SWT renderer? This would leave room for others to work on
> different renderers.
I think it would make the most sense for parties contemplating writing other
renderers for Sapphire to do that in Sapphire project. That would simplify
logistics, communication and community building. So I do not want to steer
those parties to separate projects by restricting Sapphire scope in this
way. However, if a party came a long and expressed specific interest in
building a renderer for Sapphire in another project, I would not be opposed
to amending Sapphire scope to specifically exclude that implementation.
> Can you elaborate a bit more on the differences to EMF and why EMF is
> not sufficient?
I do not wish to turn the discussion of Sapphire proposal into an expose on
EMF strengths and weaknesses. If people are interested in pursuing such
comparisons, it will be more appropriate to do that after the project is
created and code is contributed. That would allow me to explain what I mean
with code references and examples. It would also allow people to play with
the technology and see for themselves if they believe the arguments.
In rough terms, EMF is a general-purpose modeling solution and as such over
time grew to cover wide variety of scenarios. This generality necessarily
makes EMF difficult to learn. If the developer's goal is to learn modeling
and then "do modeling" in a variety of contexts, then the time investment in
learning core EMF and all the other auxiliary technologies necessary to
piece together a complete solution is likely to pay off. Sapphire targets
developers who are not necessarily interested in modeling, but they need to
write high quality UI. The task is to convince those developers that they
can be more productive almost immediately with Sapphire than writing naked
SWT code themselves. That argument is difficult to make if those developers
must learn something as complex as EMF first.
Sapphire modeling framework is not a general modeling solution and it will
never be one. It might help to think of it as a domain specific language
(DSL) over the modeling space specifically tailored to the needs of UI
developers. In some areas, it ignores large swaths of the general modeling
problem as those are not relevant to this space. In other areas, it provides
out of the box deep verticals that are essential to the needs of UI
developers, but would take a lot of scaffolding and welding to accomplish
with EMF.
I have followed e4 since its inception and saw the big "to emf or not to
emf" debate. The modeling requirements of e4 and Sapphire are quite
different. The e4 project uses modeling technology to create a model to
represent the structure of the UI. This model is written once by experts and
the developers using e4 only manipulate instances of this model. Sapphire
needs a modeling solution to represent the _data_ being edited by the UI. As
such, in order to use Sapphire, every developer must be proficient at
creating models.
Hope that clarifies,
- Konstantin
-----Original Message-----
From: Gunnar Wagenknecht [mailto:gunnar@xxxxxxxxxxxxxxx]
Sent: Friday, June 11, 2010 11:42 PM
To: Konstantin Komissarchik
Cc: Technology PMC; emo@xxxxxxxxxxx; teri.whitaker@xxxxxxxxxx;
greg.stachnick@xxxxxxxxxx; pieter.humphrey@xxxxxxxxxx
Subject: Re: [technology-pmc] Sapphire
Hi Konstantin,
Am 10.06.2010 22:07, schrieb Konstantin Komissarchik:
> We welcome your feedback on this proposal.
I think the scope needs to be more precise and limiting. Note, it is not
set for lifetime and can be adapted as the project evolves.
For example, this is too generic:
> This project will be focused on identifying ways to significantly
> speed up UI development while simultaneously improving quality,
> maintainability and consistency.
It basically opens the project to *anything* UI development related.
Also the next sentence is too open IMHO.
> Some of the key deliverables:
>From reading the proposals it sounds like point 1 and 3 should be *the*
key deliverables but not _some_.
I'd also like you to consider how others can adopt/benefit from
Sapphire. For example, can you imaging that you (initially) just focus
on the SWT renderer? This would leave room for others to work on
different renderers.
The most issue I have is a goal of delivering "A compact and easy to
learn modeling framework tailored to the needs of UI writers." That
really sounds like a second modeling framework and you admit it in the
sentence below.
>From reading "Relation to EMF" it sounds like EMF does not serve the
needs of UI developers very well. Do you know that EMF is powering e4?
e4 initially also started with their own modeling framework
implementation but soon discovered and learned that EMF does serve their
needs very well.
Can you elaborate a bit more on the differences to EMF and why EMF is
not sufficient?
-Gunnar
--
Gunnar Wagenknecht
gunnar@xxxxxxxxxxxxxxx
http://wagenknecht.org/
