Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » XML Schema Definition (XSD) » Announcement: New EMF/XSD Community Page: EMF/XSD Implementations, Solutions, Extensions
Announcement: New EMF/XSD Community Page: EMF/XSD Implementations, Solutions, Extensions [message #41755] Mon, 19 April 2004 20:25 Go to next message
Eclipse UserFriend
Originally posted by: codeslave.ca.ibm.com

Everyone:

It's been suggested that it would be cool to have a place to
discuss/share extensions and implementations that the user community has
done with EMF and/or XSD... things like for example, [your project here].

If you have some input as to what you'd like to post, see, share, etc.,
please reply to this thread. I'm looking to design some sort of
community page on eclipse.org/emf and /xsd where you could both hunt for
implementations/solutions/extensions and also share others. A little
free advertising.

If you have anything to contribute - ideas, comments, feedback, whatever
- please post it here or email me.

Thanks!

Nick Boldt :: Java Developer
Eclipse EMF and SDO Frameworks
codeslave@ca.ibm.com
Re: Announcement: New EMF/XSD Community Page: EMF/XSD Implementations, Solutions, Extensions [message #41792 is a reply to message #41755] Tue, 20 April 2004 08:50 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6515
Registered: July 2009
Senior Member
nick and everyone,

that sounds great to me. what about sdo? since persistence
issues seem to be a major concern of many engineers i'd be
pleased, if sdo would also be a topic there.

i am currently working on a proof of concept for connecting
an emf model to a relational database. a stable prototype
should be ready in 2 weeks or so. i'd like to make it open
source then and free of any license fees (ed: for my understanding
it's a "product" nevertheless ;-))

according to the special needs of my application, i formed the
top level requirements of my persistence framework like this
(in the following "persistence" refers to the ability of a model object
to persist to a relational database):

1) persistence does not necessarily have to be transparent
(a persistent class may have to extend a special base class
or implement a certain interface).
2) persistence should integrate well with generated editors.
3) at client-side the objects shall be modifiable in the context
of a transaction (with commit and rollback).
4) transactions shall use optimistic locking.
5) objects shall be "hot-connected" to the central repository
(that is, they are actively invalidated by the server on change
through one client - because of this i tend to call the framework
CDO for "connected data objects").
6) network calls shall be minimized with respect to number and size,
i.e. a CDO use case (like "load initial contents") shall result in a
single request (as opposed to the "1+N problem" of entity EJBs
for example).
7) the central store of objects shall implement a garbage collection.
8) the repository objects shall be queriable (SQL, OQL, ...)
9) of course the framework shall be convenient, stable and performant ;-)

from these requirements i derived a basic system architecture:

- three tiers are necessary to fulfill [Req6]. clients must not commuincate
directly with the database, but with a CDO server instead, that takes a
single CDO request from a client and starts chatting with the database.
the database can even be embedded for performance reasons.
- the protocol between client and CDO server is proprietary, because
most of the signalling frameworks i know (like KOI) seem to implement
the client-server paradigm (request-indication-repsonse-confirmation)
only uni-directional. JVM, the Jet Virtual Medium could possibly be
used: http://www.cs.purdue.edu/homes/sion/jvm/docs. To fulfill [Req5]
the paradigm has to be implemented bi-directional, that is the client
has also to act as a server (also known as asynchronous push service).
- the protocol is binary [Req9].
- persistent objects have a common ancestor class [AntiReq1] which
hosts a unique (long) id and a version int [Req4]. The common
ancestor class makes it possible to find a track of each object in a
single table, which is a precondition to store _all_ references to
arbitrary objects in another single table. That, in turn, enables for a
deterministic, ad-hoc garbage collection with a single jdbc call [Req7].
- the base class also has an invalidation flag that is set on change
notification of the server and triggers a reload when the object is
used the next time [Req5]+[Req6].
- object attributes (and only attributes) are stored in separate tables per
inheritance level [Req8].
- the ecore change model is used to implement client-side transactions
[Req3]. as of now they are optimized for rollbacks. for committing
changes the change description has to be reversed (and applied twice
unnecessarily). since all objects own a unique id, it should be possible
to make a change recorder that optimizes for commits, like Ed noted
recently in this group.
- the CDO server loads the EMF model and uses EMF reflection to
create the mappings and tables automagically [Req9]. Later one could
use ecore annotations to influence mappings.
- the generated editors reflect invalidations visually (by decorating the
respective nodes as invalid or by directly reloading them) [Req2].
this is not achieved, yet ;-(

there are many issues not covered by my current implementation, like
support for multi-valued attributes and user data types. further
optimizations will cover memory issues in the client (unloading of
seldomly used objects from the model) and performance issues in the
server (caching of prepared statements or even object data in memory).

i really hope that my work could be valuable for someone else, too.
and it would be cool, if others would review my ideas, give
implementation tips or even help to develop and maintain the project.

i have no experience with team based, open source development, yet,
but maybe the new site, you mentioned, is a starting point for that...

/eike


"Nick Boldt" <codeslave@ca.ibm.com> schrieb im Newsbeitrag
news:c61c8i$8qd$1@eclipse.org...
> Everyone:
>
> It's been suggested that it would be cool to have a place to
> discuss/share extensions and implementations that the user community has
> done with EMF and/or XSD... things like for example, [your project here].
>
> If you have some input as to what you'd like to post, see, share, etc.,
> please reply to this thread. I'm looking to design some sort of
> community page on eclipse.org/emf and /xsd where you could both hunt for
> implementations/solutions/extensions and also share others. A little
> free advertising.
>
> If you have anything to contribute - ideas, comments, feedback, whatever
> - please post it here or email me.
>
> Thanks!
>
> Nick Boldt :: Java Developer
> Eclipse EMF and SDO Frameworks
> codeslave@ca.ibm.com


Re: Announcement: New EMF/XSD Community Page: EMF/XSD Implementations, Solutions [message #42064 is a reply to message #41755] Tue, 20 April 2004 21:25 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: kutter.a4m.biz

We work on code where we combine one fixed Schema with an exchangable
Schema, and then we decorate the documents from the exchangable Schema
with elements comming from the fixed Schema.

Within this, we define as well pattern-matching over documents of the
exchangable Schema. Further it contains parts representing code as EMF,
and doing partial evaluation and attribute grammar like things over
EMF.

I think these parts of our code may be useful for the
community, and we plan to provide it open-source.

Another part of our code is used to implement with this infrastructure a
patented technology for executable XML.

Do you think this is a problem, if code provided for the exchange
contains parts implementing non-open technology?

For us it is not a problem, as we have an open version of our tool,
and as we purely rely on the protection of the patent, we do not hide the
code. And other people may do something useful with parts of the code.

Please let us know.

Best Regards,
Philipp



Nick Boldt wrote:

> Everyone:

> It's been suggested that it would be cool to have a place to
> discuss/share extensions and implementations that the user community has
> done with EMF and/or XSD... things like for example, [your project here].

> If you have some input as to what you'd like to post, see, share, etc.,
> please reply to this thread. I'm looking to design some sort of
> community page on eclipse.org/emf and /xsd where you could both hunt for
> implementations/solutions/extensions and also share others. A little
> free advertising.

> If you have anything to contribute - ideas, comments, feedback, whatever
> - please post it here or email me.

> Thanks!

> Nick Boldt :: Java Developer
> Eclipse EMF and SDO Frameworks
> codeslave@ca.ibm.com
Re: Announcement: New EMF/XSD Community Page: EMF/XSD Implementations, Solutions [message #42095 is a reply to message #42064] Wed, 21 April 2004 11:17 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: merks.ca.ibm.com

Philipp,

I'm most certainly not a legal expert and so what I have to say is certainly
not legal advice. ;-)

I know that at IBM we are able to open-source patented technology, so this is
not in and of itself a problem.

We've been talking to Eclipse folks about creating an Eclipse technology
project where people can host their EMF models and EMF tools and utilities for
others to share, reuse, make contributions to, or derive their own solutions
from. When we get to that point, and you are wanting to make a contribution,
you will need to get some expert legal advice.


"Philipp W. Kutter" wrote:

> We work on code where we combine one fixed Schema with an exchangable
> Schema, and then we decorate the documents from the exchangable Schema
> with elements comming from the fixed Schema.
>
> Within this, we define as well pattern-matching over documents of the
> exchangable Schema. Further it contains parts representing code as EMF,
> and doing partial evaluation and attribute grammar like things over
> EMF.
>
> I think these parts of our code may be useful for the
> community, and we plan to provide it open-source.
>
> Another part of our code is used to implement with this infrastructure a
> patented technology for executable XML.
>
> Do you think this is a problem, if code provided for the exchange
> contains parts implementing non-open technology?
>
> For us it is not a problem, as we have an open version of our tool,
> and as we purely rely on the protection of the patent, we do not hide the
> code. And other people may do something useful with parts of the code.
>
> Please let us know.
>
> Best Regards,
> Philipp
>
> Nick Boldt wrote:
>
> > Everyone:
>
> > It's been suggested that it would be cool to have a place to
> > discuss/share extensions and implementations that the user community has
> > done with EMF and/or XSD... things like for example, [your project here].
>
> > If you have some input as to what you'd like to post, see, share, etc.,
> > please reply to this thread. I'm looking to design some sort of
> > community page on eclipse.org/emf and /xsd where you could both hunt for
> > implementations/solutions/extensions and also share others. A little
> > free advertising.
>
> > If you have anything to contribute - ideas, comments, feedback, whatever
> > - please post it here or email me.
>
> > Thanks!
>
> > Nick Boldt :: Java Developer
> > Eclipse EMF and SDO Frameworks
> > codeslave@ca.ibm.com
Re: Announcement: New EMF/XSD Community Page: EMF/XSD Implementations, Solution [message #42126 is a reply to message #42095] Wed, 21 April 2004 21:13 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: kutter.a4m.biz

Hi, Ed.

I was already discussing this issue with my patent lawyer.

He said, that in principle it is no problem if we open
the code implementing our patented-technology, but we would
purely rely on the patent protection. This is perfectly
enough for us, thus we want to open-the code.

The question I had is whether the Eclipse project has a problem
if I publish code which has a licence saying:

"You can do with this code whatever you want, except what is
claimed by patent XXX.

This licence is not a licence to the technology protected by
patent XXX. It is therefore not allowed to use the complete
code as it is, since this will infringe patent XXX.

This code can be reuse as part of any system or tool which is not
protected by the claims of patent XXX."



I fear my lawyer cannot answer whether this is a problem for the
Eclipse project.

The best what I can think of, was going again for lunch with Erich Gamma,
who has his office around the corner. But I wanted to meet next time with
him, when I can show him our EMF application ;-)

Best, Philipp


Ed Merks wrote:

> Philipp,

> I'm most certainly not a legal expert and so what I have to say is certainly
> not legal advice. ;-)

> I know that at IBM we are able to open-source patented technology, so this is
> not in and of itself a problem.

> We've been talking to Eclipse folks about creating an Eclipse technology
> project where people can host their EMF models and EMF tools and utilities
for
> others to share, reuse, make contributions to, or derive their own solutions
> from. When we get to that point, and you are wanting to make a contribution,
> you will need to get some expert legal advice.


> "Philipp W. Kutter" wrote:

> > We work on code where we combine one fixed Schema with an exchangable
> > Schema, and then we decorate the documents from the exchangable Schema
> > with elements comming from the fixed Schema.
> >
> > Within this, we define as well pattern-matching over documents of the
> > exchangable Schema. Further it contains parts representing code as EMF,
> > and doing partial evaluation and attribute grammar like things over
> > EMF.
> >
> > I think these parts of our code may be useful for the
> > community, and we plan to provide it open-source.
> >
> > Another part of our code is used to implement with this infrastructure a
> > patented technology for executable XML.
> >
> > Do you think this is a problem, if code provided for the exchange
> > contains parts implementing non-open technology?
> >
> > For us it is not a problem, as we have an open version of our tool,
> > and as we purely rely on the protection of the patent, we do not hide the
> > code. And other people may do something useful with parts of the code.
> >
> > Please let us know.
> >
> > Best Regards,
> > Philipp
> >
> > Nick Boldt wrote:
> >
> > > Everyone:
> >
> > > It's been suggested that it would be cool to have a place to
> > > discuss/share extensions and implementations that the user community has
> > > done with EMF and/or XSD... things like for example, [your project here].
> >
> > > If you have some input as to what you'd like to post, see, share, etc.,
> > > please reply to this thread. I'm looking to design some sort of
> > > community page on eclipse.org/emf and /xsd where you could both hunt for
> > > implementations/solutions/extensions and also share others. A little
> > > free advertising.
> >
> > > If you have anything to contribute - ideas, comments, feedback, whatever
> > > - please post it here or email me.
> >
> > > Thanks!
> >
> > > Nick Boldt :: Java Developer
> > > Eclipse EMF and SDO Frameworks
> > > codeslave@ca.ibm.com
Re: Announcement: New EMF/XSD Community Page: EMF/XSD Implementations, Solution [message #42157 is a reply to message #42126] Wed, 21 April 2004 22:58 Go to previous messageGo to next message
Adrian Cho is currently offline Adrian ChoFriend
Messages: 18
Registered: July 2009
Junior Member
Philipp, Ed

I work for IBM on some of the legal issues involving our participation in
Eclipse and I also assist the PMCs in dealing with some of these issues. To
do what Philipp is suggesting, I recommend you use the following procedure:

The lead for the component that wishes to incorporate this code should bring
it to the attention of the relevant PMC. PMCs may at their discretion
accept (and subsequently) relicense code under other licenses (which is
basically what this would be - the CPL plus additional terms) and they
usually do so with legal advice. Every case is different - it depends on
what the other license terms and conditions are and what the code is and why
the project requires it.

If the PMC approves this, we will ensure that the legal documentation (e.g.
the about.html for the plug-in containing this content) is correct and flows
down the necessary terms and conditions.

If I understand it correctly, the code Philipp would contribute to
Eclipse.org does not in itself implement any patented invention but when
combined with some other code there is a patent that it reads on? That
question and likely others need to be answered first. This is not the best
forum to discuss these types of issues so I suggest that you bring this to
the attention of the PMC and we can work out what to do.

Adrian

Adrian Cho
Manager, Intellectual Property
IBM

"Philipp W. Kutter" <kutter@a4m.biz> wrote in message
news:c66o5n$tjb$1@eclipse.org...
> Hi, Ed.
>
> I was already discussing this issue with my patent lawyer.
>
> He said, that in principle it is no problem if we open
> the code implementing our patented-technology, but we would
> purely rely on the patent protection. This is perfectly
> enough for us, thus we want to open-the code.
>
> The question I had is whether the Eclipse project has a problem
> if I publish code which has a licence saying:
>
> "You can do with this code whatever you want, except what is
> claimed by patent XXX.
>
> This licence is not a licence to the technology protected by
> patent XXX. It is therefore not allowed to use the complete
> code as it is, since this will infringe patent XXX.
>
> This code can be reuse as part of any system or tool which is not
> protected by the claims of patent XXX."
>
>
>
> I fear my lawyer cannot answer whether this is a problem for the
> Eclipse project.
>
> The best what I can think of, was going again for lunch with Erich Gamma,
> who has his office around the corner. But I wanted to meet next time with
> him, when I can show him our EMF application ;-)
>
> Best, Philipp
>
>
> Ed Merks wrote:
>
> > Philipp,
>
> > I'm most certainly not a legal expert and so what I have to say is
certainly
> > not legal advice. ;-)
>
> > I know that at IBM we are able to open-source patented technology, so
this is
> > not in and of itself a problem.
>
> > We've been talking to Eclipse folks about creating an Eclipse technology
> > project where people can host their EMF models and EMF tools and
utilities
> for
> > others to share, reuse, make contributions to, or derive their own
solutions
> > from. When we get to that point, and you are wanting to make a
contribution,
> > you will need to get some expert legal advice.
>
>
> > "Philipp W. Kutter" wrote:
>
> > > We work on code where we combine one fixed Schema with an exchangable
> > > Schema, and then we decorate the documents from the exchangable Schema
> > > with elements comming from the fixed Schema.
> > >
> > > Within this, we define as well pattern-matching over documents of the
> > > exchangable Schema. Further it contains parts representing code as
EMF,
> > > and doing partial evaluation and attribute grammar like things over
> > > EMF.
> > >
> > > I think these parts of our code may be useful for the
> > > community, and we plan to provide it open-source.
> > >
> > > Another part of our code is used to implement with this infrastructure
a
> > > patented technology for executable XML.
> > >
> > > Do you think this is a problem, if code provided for the exchange
> > > contains parts implementing non-open technology?
> > >
> > > For us it is not a problem, as we have an open version of our tool,
> > > and as we purely rely on the protection of the patent, we do not hide
the
> > > code. And other people may do something useful with parts of the code.
> > >
> > > Please let us know.
> > >
> > > Best Regards,
> > > Philipp
> > >
> > > Nick Boldt wrote:
> > >
> > > > Everyone:
> > >
> > > > It's been suggested that it would be cool to have a place to
> > > > discuss/share extensions and implementations that the user community
has
> > > > done with EMF and/or XSD... things like for example, [your project
here].
> > >
> > > > If you have some input as to what you'd like to post, see, share,
etc.,
> > > > please reply to this thread. I'm looking to design some sort of
> > > > community page on eclipse.org/emf and /xsd where you could both hunt
for
> > > > implementations/solutions/extensions and also share others. A little
> > > > free advertising.
> > >
> > > > If you have anything to contribute - ideas, comments, feedback,
whatever
> > > > - please post it here or email me.
> > >
> > > > Thanks!
> > >
> > > > Nick Boldt :: Java Developer
> > > > Eclipse EMF and SDO Frameworks
> > > > codeslave@ca.ibm.com
>
>
Re: Announcement: New EMF/XSD Community Page: EMF/XSD Implementations, Solution [message #42205 is a reply to message #42157] Fri, 23 April 2004 23:08 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: kutter.a4m.biz

Dear Adrian.
Thanks for the answer. I will discuss the issue with the PMC. Who would
be the relevant PMC for an EMC based contribution?

> If I understand it correctly, the code Philipp would contribute to
> Eclipse.org does not in itself implement any patented invention but when
> combined with some other code there is a patent that it reads on?

It would be rather the other way around: the code is implementing patented
technology, but if you leave one part away, it does not fall under patent
protection anymore.

The patented technology is a Schema->EMF->AbstractMachine technology,
and the EMF->AbstractMachine part alone is not protected, but as well
useful.

As well some subsets of the Schema->EMF->AbstractMachine are not protected,
only the full method is protected. Thesee subsets solve, or give hints how
to solve generally interesting problems, such as attribute grammars over
EMF or pattern matching over EMF.


The purpose of the contribution would be to let people profit from the
subsets of the functionality which do not fall under the patent protection.

Best, Philipp


Adrian Cho wrote:

> Philipp, Ed

> I work for IBM on some of the legal issues involving our participation in
> Eclipse and I also assist the PMCs in dealing with some of these issues. To
> do what Philipp is suggesting, I recommend you use the following procedure:

> The lead for the component that wishes to incorporate this code should bring
> it to the attention of the relevant PMC. PMCs may at their discretion
> accept (and subsequently) relicense code under other licenses (which is
> basically what this would be - the CPL plus additional terms) and they
> usually do so with legal advice. Every case is different - it depends on
> what the other license terms and conditions are and what the code is and why
> the project requires it.

> If the PMC approves this, we will ensure that the legal documentation (e.g.
> the about.html for the plug-in containing this content) is correct and flows
> down the necessary terms and conditions.

> If I understand it correctly, the code Philipp would contribute to
> Eclipse.org does not in itself implement any patented invention but when
> combined with some other code there is a patent that it reads on? That
> question and likely others need to be answered first. This is not the best
> forum to discuss these types of issues so I suggest that you bring this to
> the attention of the PMC and we can work out what to do.

> Adrian

> Adrian Cho
> Manager, Intellectual Property
> IBM

> "Philipp W. Kutter" <kutter@a4m.biz> wrote in message
> news:c66o5n$tjb$1@eclipse.org...
> > Hi, Ed.
> >
> > I was already discussing this issue with my patent lawyer.
> >
> > He said, that in principle it is no problem if we open
> > the code implementing our patented-technology, but we would
> > purely rely on the patent protection. This is perfectly
> > enough for us, thus we want to open-the code.
> >
> > The question I had is whether the Eclipse project has a problem
> > if I publish code which has a licence saying:
> >
> > "You can do with this code whatever you want, except what is
> > claimed by patent XXX.
> >
> > This licence is not a licence to the technology protected by
> > patent XXX. It is therefore not allowed to use the complete
> > code as it is, since this will infringe patent XXX.
> >
> > This code can be reuse as part of any system or tool which is not
> > protected by the claims of patent XXX."
> >
> >
> >
> > I fear my lawyer cannot answer whether this is a problem for the
> > Eclipse project.
> >
> > The best what I can think of, was going again for lunch with Erich Gamma,
> > who has his office around the corner. But I wanted to meet next time with
> > him, when I can show him our EMF application ;-)
> >
> > Best, Philipp
> >
> >
> > Ed Merks wrote:
> >
> > > Philipp,
> >
> > > I'm most certainly not a legal expert and so what I have to say is
> certainly
> > > not legal advice. ;-)
> >
> > > I know that at IBM we are able to open-source patented technology, so
> this is
> > > not in and of itself a problem.
> >
> > > We've been talking to Eclipse folks about creating an Eclipse technology
> > > project where people can host their EMF models and EMF tools and
> utilities
> > for
> > > others to share, reuse, make contributions to, or derive their own
> solutions
> > > from. When we get to that point, and you are wanting to make a
> contribution,
> > > you will need to get some expert legal advice.
> >
> >
> > > "Philipp W. Kutter" wrote:
> >
> > > > We work on code where we combine one fixed Schema with an exchangable
> > > > Schema, and then we decorate the documents from the exchangable Schema
> > > > with elements comming from the fixed Schema.
> > > >
> > > > Within this, we define as well pattern-matching over documents of the
> > > > exchangable Schema. Further it contains parts representing code as
> EMF,
> > > > and doing partial evaluation and attribute grammar like things over
> > > > EMF.
> > > >
> > > > I think these parts of our code may be useful for the
> > > > community, and we plan to provide it open-source.
> > > >
> > > > Another part of our code is used to implement with this infrastructure
> a
> > > > patented technology for executable XML.
> > > >
> > > > Do you think this is a problem, if code provided for the exchange
> > > > contains parts implementing non-open technology?
> > > >
> > > > For us it is not a problem, as we have an open version of our tool,
> > > > and as we purely rely on the protection of the patent, we do not hide
> the
> > > > code. And other people may do something useful with parts of the code.
> > > >
> > > > Please let us know.
> > > >
> > > > Best Regards,
> > > > Philipp
> > > >
> > > > Nick Boldt wrote:
> > > >
> > > > > Everyone:
> > > >
> > > > > It's been suggested that it would be cool to have a place to
> > > > > discuss/share extensions and implementations that the user community
> has
> > > > > done with EMF and/or XSD... things like for example, [your project
> here].
> > > >
> > > > > If you have some input as to what you'd like to post, see, share,
> etc.,
> > > > > please reply to this thread. I'm looking to design some sort of
> > > > > community page on eclipse.org/emf and /xsd where you could both hunt
> for
> > > > > implementations/solutions/extensions and also share others. A little
> > > > > free advertising.
> > > >
> > > > > If you have anything to contribute - ideas, comments, feedback,
> whatever
> > > > > - please post it here or email me.
> > > >
> > > > > Thanks!
> > > >
> > > > > Nick Boldt :: Java Developer
> > > > > Eclipse EMF and SDO Frameworks
> > > > > codeslave@ca.ibm.com
> >
> >
Classifying Community Page Submissions (was Re: Announcement: New EMF/XSD Community Page: EMF/XSD Im [message #42601 is a reply to message #41792] Wed, 28 April 2004 19:09 Go to previous message
Eclipse UserFriend
Originally posted by: codeslave.ca.ibm.com

Can't see any reason to exclude SDO from this community page. However,
let me ask the question:

Should SDO contributions be categorized differently than EMF
contributions? Or since SDO is a part of the larger EMF, should these
contributions simply be lumped in with the rest of the EMF stuff?

I can see benefits either way - I'm curious what the consensus is among
those who use EMF and SDO regularly, plus the general feeling re: which
would be more useful to other users/newbies to approach/use your
contributions.

Actually, that gets me into another realm where you all can assist me.
Admittedly it's a little cart-before-horse, but if you were going to
have to search thru a database of these implementations, solutions,
extensions, etc... what would be some common keywords, categories,
classifications, etc. that would allow people to either browse or search
more easily? Should the process of submitting involve provision of some
meta-information regarding this classification/categorization (a few
simple questions, along with contact info [email, website, other])?

That is - if you want to contribute - what's the best, simplest way to
both describe your submission and make it easily findable by others?

Thanks!

Nick Boldt
codeslave@ca.ibm.com


Eike Stepper wrote:
> nick and everyone,
>
> that sounds great to me. what about sdo? since persistence
> issues seem to be a major concern of many engineers i'd be
> pleased, if sdo would also be a topic there.
>
> i am currently working on a proof of concept for connecting
> an emf model to a relational database. a stable prototype
> should be ready in 2 weeks or so. i'd like to make it open
> source then and free of any license fees (ed: for my understanding
> it's a "product" nevertheless ;-))
>
> according to the special needs of my application, i formed the
> top level requirements of my persistence framework like this
> (in the following "persistence" refers to the ability of a model object
> to persist to a relational database):
>
> 1) persistence does not necessarily have to be transparent
> (a persistent class may have to extend a special base class
> or implement a certain interface).
> 2) persistence should integrate well with generated editors.
> 3) at client-side the objects shall be modifiable in the context
> of a transaction (with commit and rollback).
> 4) transactions shall use optimistic locking.
> 5) objects shall be "hot-connected" to the central repository
> (that is, they are actively invalidated by the server on change
> through one client - because of this i tend to call the framework
> CDO for "connected data objects").
> 6) network calls shall be minimized with respect to number and size,
> i.e. a CDO use case (like "load initial contents") shall result in a
> single request (as opposed to the "1+N problem" of entity EJBs
> for example).
> 7) the central store of objects shall implement a garbage collection.
> 8) the repository objects shall be queriable (SQL, OQL, ...)
> 9) of course the framework shall be convenient, stable and performant ;-)
>
> from these requirements i derived a basic system architecture:
>
> - three tiers are necessary to fulfill [Req6]. clients must not commuincate
> directly with the database, but with a CDO server instead, that takes a
> single CDO request from a client and starts chatting with the database.
> the database can even be embedded for performance reasons.
> - the protocol between client and CDO server is proprietary, because
> most of the signalling frameworks i know (like KOI) seem to implement
> the client-server paradigm (request-indication-repsonse-confirmation)
> only uni-directional. JVM, the Jet Virtual Medium could possibly be
> used: http://www.cs.purdue.edu/homes/sion/jvm/docs. To fulfill [Req5]
> the paradigm has to be implemented bi-directional, that is the client
> has also to act as a server (also known as asynchronous push service).
> - the protocol is binary [Req9].
> - persistent objects have a common ancestor class [AntiReq1] which
> hosts a unique (long) id and a version int [Req4]. The common
> ancestor class makes it possible to find a track of each object in a
> single table, which is a precondition to store _all_ references to
> arbitrary objects in another single table. That, in turn, enables for a
> deterministic, ad-hoc garbage collection with a single jdbc call [Req7].
> - the base class also has an invalidation flag that is set on change
> notification of the server and triggers a reload when the object is
> used the next time [Req5]+[Req6].
> - object attributes (and only attributes) are stored in separate tables per
> inheritance level [Req8].
> - the ecore change model is used to implement client-side transactions
> [Req3]. as of now they are optimized for rollbacks. for committing
> changes the change description has to be reversed (and applied twice
> unnecessarily). since all objects own a unique id, it should be possible
> to make a change recorder that optimizes for commits, like Ed noted
> recently in this group.
> - the CDO server loads the EMF model and uses EMF reflection to
> create the mappings and tables automagically [Req9]. Later one could
> use ecore annotations to influence mappings.
> - the generated editors reflect invalidations visually (by decorating the
> respective nodes as invalid or by directly reloading them) [Req2].
> this is not achieved, yet ;-(
>
> there are many issues not covered by my current implementation, like
> support for multi-valued attributes and user data types. further
> optimizations will cover memory issues in the client (unloading of
> seldomly used objects from the model) and performance issues in the
> server (caching of prepared statements or even object data in memory).
>
> i really hope that my work could be valuable for someone else, too.
> and it would be cool, if others would review my ideas, give
> implementation tips or even help to develop and maintain the project.
>
> i have no experience with team based, open source development, yet,
> but maybe the new site, you mentioned, is a starting point for that...
>
> /eike
>
>
> "Nick Boldt" <codeslave@ca.ibm.com> schrieb im Newsbeitrag
> news:c61c8i$8qd$1@eclipse.org...
>
>>Everyone:
>>
>>It's been suggested that it would be cool to have a place to
>>discuss/share extensions and implementations that the user community has
>>done with EMF and/or XSD... things like for example, [your project here].
>>
>>If you have some input as to what you'd like to post, see, share, etc.,
>>please reply to this thread. I'm looking to design some sort of
>>community page on eclipse.org/emf and /xsd where you could both hunt for
>>implementations/solutions/extensions and also share others. A little
>>free advertising.
>>
>>If you have anything to contribute - ideas, comments, feedback, whatever
>>- please post it here or email me.
>>
>>Thanks!
>>
>>Nick Boldt :: Java Developer
>>Eclipse EMF and SDO Frameworks
>>codeslave@ca.ibm.com
>
>
>
Re: Announcement: New EMF/XSD Community Page: EMF/XSD Implementations, Solutions, Extensions [message #585798 is a reply to message #41755] Tue, 20 April 2004 08:50 Go to previous message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6515
Registered: July 2009
Senior Member
nick and everyone,

that sounds great to me. what about sdo? since persistence
issues seem to be a major concern of many engineers i'd be
pleased, if sdo would also be a topic there.

i am currently working on a proof of concept for connecting
an emf model to a relational database. a stable prototype
should be ready in 2 weeks or so. i'd like to make it open
source then and free of any license fees (ed: for my understanding
it's a "product" nevertheless ;-))

according to the special needs of my application, i formed the
top level requirements of my persistence framework like this
(in the following "persistence" refers to the ability of a model object
to persist to a relational database):

1) persistence does not necessarily have to be transparent
(a persistent class may have to extend a special base class
or implement a certain interface).
2) persistence should integrate well with generated editors.
3) at client-side the objects shall be modifiable in the context
of a transaction (with commit and rollback).
4) transactions shall use optimistic locking.
5) objects shall be "hot-connected" to the central repository
(that is, they are actively invalidated by the server on change
through one client - because of this i tend to call the framework
CDO for "connected data objects").
6) network calls shall be minimized with respect to number and size,
i.e. a CDO use case (like "load initial contents") shall result in a
single request (as opposed to the "1+N problem" of entity EJBs
for example).
7) the central store of objects shall implement a garbage collection.
8) the repository objects shall be queriable (SQL, OQL, ...)
9) of course the framework shall be convenient, stable and performant ;-)

from these requirements i derived a basic system architecture:

- three tiers are necessary to fulfill [Req6]. clients must not commuincate
directly with the database, but with a CDO server instead, that takes a
single CDO request from a client and starts chatting with the database.
the database can even be embedded for performance reasons.
- the protocol between client and CDO server is proprietary, because
most of the signalling frameworks i know (like KOI) seem to implement
the client-server paradigm (request-indication-repsonse-confirmation)
only uni-directional. JVM, the Jet Virtual Medium could possibly be
used: http://www.cs.purdue.edu/homes/sion/jvm/docs To fulfill [Req5]
the paradigm has to be implemented bi-directional, that is the client
has also to act as a server (also known as asynchronous push service).
- the protocol is binary [Req9].
- persistent objects have a common ancestor class [AntiReq1] which
hosts a unique (long) id and a version int [Req4]. The common
ancestor class makes it possible to find a track of each object in a
single table, which is a precondition to store _all_ references to
arbitrary objects in another single table. That, in turn, enables for a
deterministic, ad-hoc garbage collection with a single jdbc call [Req7].
- the base class also has an invalidation flag that is set on change
notification of the server and triggers a reload when the object is
used the next time [Req5]+[Req6].
- object attributes (and only attributes) are stored in separate tables per
inheritance level [Req8].
- the ecore change model is used to implement client-side transactions
[Req3]. as of now they are optimized for rollbacks. for committing
changes the change description has to be reversed (and applied twice
unnecessarily). since all objects own a unique id, it should be possible
to make a change recorder that optimizes for commits, like Ed noted
recently in this group.
- the CDO server loads the EMF model and uses EMF reflection to
create the mappings and tables automagically [Req9]. Later one could
use ecore annotations to influence mappings.
- the generated editors reflect invalidations visually (by decorating the
respective nodes as invalid or by directly reloading them) [Req2].
this is not achieved, yet ;-(

there are many issues not covered by my current implementation, like
support for multi-valued attributes and user data types. further
optimizations will cover memory issues in the client (unloading of
seldomly used objects from the model) and performance issues in the
server (caching of prepared statements or even object data in memory).

i really hope that my work could be valuable for someone else, too.
and it would be cool, if others would review my ideas, give
implementation tips or even help to develop and maintain the project.

i have no experience with team based, open source development, yet,
but maybe the new site, you mentioned, is a starting point for that...

/eike


"Nick Boldt" <codeslave@ca.ibm.com> schrieb im Newsbeitrag
news:c61c8i$8qd$1@eclipse.org...
> Everyone:
>
> It's been suggested that it would be cool to have a place to
> discuss/share extensions and implementations that the user community has
> done with EMF and/or XSD... things like for example, [your project here].
>
> If you have some input as to what you'd like to post, see, share, etc.,
> please reply to this thread. I'm looking to design some sort of
> community page on eclipse.org/emf and /xsd where you could both hunt for
> implementations/solutions/extensions and also share others. A little
> free advertising.
>
> If you have anything to contribute - ideas, comments, feedback, whatever
> - please post it here or email me.
>
> Thanks!
>
> Nick Boldt :: Java Developer
> Eclipse EMF and SDO Frameworks
> codeslave@ca.ibm.com


Re: Announcement: New EMF/XSD Community Page: EMF/XSD Implementations, Solutions [message #585928 is a reply to message #41755] Tue, 20 April 2004 21:25 Go to previous message
Eclipse UserFriend
Originally posted by: kutter.a4m.biz

We work on code where we combine one fixed Schema with an exchangable
Schema, and then we decorate the documents from the exchangable Schema
with elements comming from the fixed Schema.

Within this, we define as well pattern-matching over documents of the
exchangable Schema. Further it contains parts representing code as EMF,
and doing partial evaluation and attribute grammar like things over
EMF.

I think these parts of our code may be useful for the
community, and we plan to provide it open-source.

Another part of our code is used to implement with this infrastructure a
patented technology for executable XML.

Do you think this is a problem, if code provided for the exchange
contains parts implementing non-open technology?

For us it is not a problem, as we have an open version of our tool,
and as we purely rely on the protection of the patent, we do not hide the
code. And other people may do something useful with parts of the code.

Please let us know.

Best Regards,
Philipp



Nick Boldt wrote:

> Everyone:

> It's been suggested that it would be cool to have a place to
> discuss/share extensions and implementations that the user community has
> done with EMF and/or XSD... things like for example, [your project here].

> If you have some input as to what you'd like to post, see, share, etc.,
> please reply to this thread. I'm looking to design some sort of
> community page on eclipse.org/emf and /xsd where you could both hunt for
> implementations/solutions/extensions and also share others. A little
> free advertising.

> If you have anything to contribute - ideas, comments, feedback, whatever
> - please post it here or email me.

> Thanks!

> Nick Boldt :: Java Developer
> Eclipse EMF and SDO Frameworks
> codeslave@ca.ibm.com
Re: Announcement: New EMF/XSD Community Page: EMF/XSD Implementations, Solutions [message #585941 is a reply to message #42064] Wed, 21 April 2004 11:17 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 31540
Registered: July 2009
Senior Member
Philipp,

I'm most certainly not a legal expert and so what I have to say is certainly
not legal advice. ;-)

I know that at IBM we are able to open-source patented technology, so this is
not in and of itself a problem.

We've been talking to Eclipse folks about creating an Eclipse technology
project where people can host their EMF models and EMF tools and utilities for
others to share, reuse, make contributions to, or derive their own solutions
from. When we get to that point, and you are wanting to make a contribution,
you will need to get some expert legal advice.


"Philipp W. Kutter" wrote:

> We work on code where we combine one fixed Schema with an exchangable
> Schema, and then we decorate the documents from the exchangable Schema
> with elements comming from the fixed Schema.
>
> Within this, we define as well pattern-matching over documents of the
> exchangable Schema. Further it contains parts representing code as EMF,
> and doing partial evaluation and attribute grammar like things over
> EMF.
>
> I think these parts of our code may be useful for the
> community, and we plan to provide it open-source.
>
> Another part of our code is used to implement with this infrastructure a
> patented technology for executable XML.
>
> Do you think this is a problem, if code provided for the exchange
> contains parts implementing non-open technology?
>
> For us it is not a problem, as we have an open version of our tool,
> and as we purely rely on the protection of the patent, we do not hide the
> code. And other people may do something useful with parts of the code.
>
> Please let us know.
>
> Best Regards,
> Philipp
>
> Nick Boldt wrote:
>
> > Everyone:
>
> > It's been suggested that it would be cool to have a place to
> > discuss/share extensions and implementations that the user community has
> > done with EMF and/or XSD... things like for example, [your project here].
>
> > If you have some input as to what you'd like to post, see, share, etc.,
> > please reply to this thread. I'm looking to design some sort of
> > community page on eclipse.org/emf and /xsd where you could both hunt for
> > implementations/solutions/extensions and also share others. A little
> > free advertising.
>
> > If you have anything to contribute - ideas, comments, feedback, whatever
> > - please post it here or email me.
>
> > Thanks!
>
> > Nick Boldt :: Java Developer
> > Eclipse EMF and SDO Frameworks
> > codeslave@ca.ibm.com


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: Announcement: New EMF/XSD Community Page: EMF/XSD Implementations, Solution [message #585968 is a reply to message #42095] Wed, 21 April 2004 21:13 Go to previous message
Eclipse UserFriend
Originally posted by: kutter.a4m.biz

Hi, Ed.

I was already discussing this issue with my patent lawyer.

He said, that in principle it is no problem if we open
the code implementing our patented-technology, but we would
purely rely on the patent protection. This is perfectly
enough for us, thus we want to open-the code.

The question I had is whether the Eclipse project has a problem
if I publish code which has a licence saying:

"You can do with this code whatever you want, except what is
claimed by patent XXX.

This licence is not a licence to the technology protected by
patent XXX. It is therefore not allowed to use the complete
code as it is, since this will infringe patent XXX.

This code can be reuse as part of any system or tool which is not
protected by the claims of patent XXX."



I fear my lawyer cannot answer whether this is a problem for the
Eclipse project.

The best what I can think of, was going again for lunch with Erich Gamma,
who has his office around the corner. But I wanted to meet next time with
him, when I can show him our EMF application ;-)

Best, Philipp


Ed Merks wrote:

> Philipp,

> I'm most certainly not a legal expert and so what I have to say is certainly
> not legal advice. ;-)

> I know that at IBM we are able to open-source patented technology, so this is
> not in and of itself a problem.

> We've been talking to Eclipse folks about creating an Eclipse technology
> project where people can host their EMF models and EMF tools and utilities
for
> others to share, reuse, make contributions to, or derive their own solutions
> from. When we get to that point, and you are wanting to make a contribution,
> you will need to get some expert legal advice.


> "Philipp W. Kutter" wrote:

> > We work on code where we combine one fixed Schema with an exchangable
> > Schema, and then we decorate the documents from the exchangable Schema
> > with elements comming from the fixed Schema.
> >
> > Within this, we define as well pattern-matching over documents of the
> > exchangable Schema. Further it contains parts representing code as EMF,
> > and doing partial evaluation and attribute grammar like things over
> > EMF.
> >
> > I think these parts of our code may be useful for the
> > community, and we plan to provide it open-source.
> >
> > Another part of our code is used to implement with this infrastructure a
> > patented technology for executable XML.
> >
> > Do you think this is a problem, if code provided for the exchange
> > contains parts implementing non-open technology?
> >
> > For us it is not a problem, as we have an open version of our tool,
> > and as we purely rely on the protection of the patent, we do not hide the
> > code. And other people may do something useful with parts of the code.
> >
> > Please let us know.
> >
> > Best Regards,
> > Philipp
> >
> > Nick Boldt wrote:
> >
> > > Everyone:
> >
> > > It's been suggested that it would be cool to have a place to
> > > discuss/share extensions and implementations that the user community has
> > > done with EMF and/or XSD... things like for example, [your project here].
> >
> > > If you have some input as to what you'd like to post, see, share, etc.,
> > > please reply to this thread. I'm looking to design some sort of
> > > community page on eclipse.org/emf and /xsd where you could both hunt for
> > > implementations/solutions/extensions and also share others. A little
> > > free advertising.
> >
> > > If you have anything to contribute - ideas, comments, feedback, whatever
> > > - please post it here or email me.
> >
> > > Thanks!
> >
> > > Nick Boldt :: Java Developer
> > > Eclipse EMF and SDO Frameworks
> > > codeslave@ca.ibm.com
Re: Announcement: New EMF/XSD Community Page: EMF/XSD Implementations, Solution [message #585978 is a reply to message #42126] Wed, 21 April 2004 22:58 Go to previous message
Adrian Cho is currently offline Adrian ChoFriend
Messages: 18
Registered: July 2009
Junior Member
Philipp, Ed

I work for IBM on some of the legal issues involving our participation in
Eclipse and I also assist the PMCs in dealing with some of these issues. To
do what Philipp is suggesting, I recommend you use the following procedure:

The lead for the component that wishes to incorporate this code should bring
it to the attention of the relevant PMC. PMCs may at their discretion
accept (and subsequently) relicense code under other licenses (which is
basically what this would be - the CPL plus additional terms) and they
usually do so with legal advice. Every case is different - it depends on
what the other license terms and conditions are and what the code is and why
the project requires it.

If the PMC approves this, we will ensure that the legal documentation (e.g.
the about.html for the plug-in containing this content) is correct and flows
down the necessary terms and conditions.

If I understand it correctly, the code Philipp would contribute to
Eclipse.org does not in itself implement any patented invention but when
combined with some other code there is a patent that it reads on? That
question and likely others need to be answered first. This is not the best
forum to discuss these types of issues so I suggest that you bring this to
the attention of the PMC and we can work out what to do.

Adrian

Adrian Cho
Manager, Intellectual Property
IBM

"Philipp W. Kutter" <kutter@a4m.biz> wrote in message
news:c66o5n$tjb$1@eclipse.org...
> Hi, Ed.
>
> I was already discussing this issue with my patent lawyer.
>
> He said, that in principle it is no problem if we open
> the code implementing our patented-technology, but we would
> purely rely on the patent protection. This is perfectly
> enough for us, thus we want to open-the code.
>
> The question I had is whether the Eclipse project has a problem
> if I publish code which has a licence saying:
>
> "You can do with this code whatever you want, except what is
> claimed by patent XXX.
>
> This licence is not a licence to the technology protected by
> patent XXX. It is therefore not allowed to use the complete
> code as it is, since this will infringe patent XXX.
>
> This code can be reuse as part of any system or tool which is not
> protected by the claims of patent XXX."
>
>
>
> I fear my lawyer cannot answer whether this is a problem for the
> Eclipse project.
>
> The best what I can think of, was going again for lunch with Erich Gamma,
> who has his office around the corner. But I wanted to meet next time with
> him, when I can show him our EMF application ;-)
>
> Best, Philipp
>
>
> Ed Merks wrote:
>
> > Philipp,
>
> > I'm most certainly not a legal expert and so what I have to say is
certainly
> > not legal advice. ;-)
>
> > I know that at IBM we are able to open-source patented technology, so
this is
> > not in and of itself a problem.
>
> > We've been talking to Eclipse folks about creating an Eclipse technology
> > project where people can host their EMF models and EMF tools and
utilities
> for
> > others to share, reuse, make contributions to, or derive their own
solutions
> > from. When we get to that point, and you are wanting to make a
contribution,
> > you will need to get some expert legal advice.
>
>
> > "Philipp W. Kutter" wrote:
>
> > > We work on code where we combine one fixed Schema with an exchangable
> > > Schema, and then we decorate the documents from the exchangable Schema
> > > with elements comming from the fixed Schema.
> > >
> > > Within this, we define as well pattern-matching over documents of the
> > > exchangable Schema. Further it contains parts representing code as
EMF,
> > > and doing partial evaluation and attribute grammar like things over
> > > EMF.
> > >
> > > I think these parts of our code may be useful for the
> > > community, and we plan to provide it open-source.
> > >
> > > Another part of our code is used to implement with this infrastructure
a
> > > patented technology for executable XML.
> > >
> > > Do you think this is a problem, if code provided for the exchange
> > > contains parts implementing non-open technology?
> > >
> > > For us it is not a problem, as we have an open version of our tool,
> > > and as we purely rely on the protection of the patent, we do not hide
the
> > > code. And other people may do something useful with parts of the code.
> > >
> > > Please let us know.
> > >
> > > Best Regards,
> > > Philipp
> > >
> > > Nick Boldt wrote:
> > >
> > > > Everyone:
> > >
> > > > It's been suggested that it would be cool to have a place to
> > > > discuss/share extensions and implementations that the user community
has
> > > > done with EMF and/or XSD... things like for example, [your project
here].
> > >
> > > > If you have some input as to what you'd like to post, see, share,
etc.,
> > > > please reply to this thread. I'm looking to design some sort of
> > > > community page on eclipse.org/emf and /xsd where you could both hunt
for
> > > > implementations/solutions/extensions and also share others. A little
> > > > free advertising.
> > >
> > > > If you have anything to contribute - ideas, comments, feedback,
whatever
> > > > - please post it here or email me.
> > >
> > > > Thanks!
> > >
> > > > Nick Boldt :: Java Developer
> > > > Eclipse EMF and SDO Frameworks
> > > > codeslave@ca.ibm.com
>
>
Re: Announcement: New EMF/XSD Community Page: EMF/XSD Implementations, Solution [message #586000 is a reply to message #42157] Fri, 23 April 2004 23:08 Go to previous message
Eclipse UserFriend
Originally posted by: kutter.a4m.biz

Dear Adrian.
Thanks for the answer. I will discuss the issue with the PMC. Who would
be the relevant PMC for an EMC based contribution?

> If I understand it correctly, the code Philipp would contribute to
> Eclipse.org does not in itself implement any patented invention but when
> combined with some other code there is a patent that it reads on?

It would be rather the other way around: the code is implementing patented
technology, but if you leave one part away, it does not fall under patent
protection anymore.

The patented technology is a Schema->EMF->AbstractMachine technology,
and the EMF->AbstractMachine part alone is not protected, but as well
useful.

As well some subsets of the Schema->EMF->AbstractMachine are not protected,
only the full method is protected. Thesee subsets solve, or give hints how
to solve generally interesting problems, such as attribute grammars over
EMF or pattern matching over EMF.


The purpose of the contribution would be to let people profit from the
subsets of the functionality which do not fall under the patent protection.

Best, Philipp


Adrian Cho wrote:

> Philipp, Ed

> I work for IBM on some of the legal issues involving our participation in
> Eclipse and I also assist the PMCs in dealing with some of these issues. To
> do what Philipp is suggesting, I recommend you use the following procedure:

> The lead for the component that wishes to incorporate this code should bring
> it to the attention of the relevant PMC. PMCs may at their discretion
> accept (and subsequently) relicense code under other licenses (which is
> basically what this would be - the CPL plus additional terms) and they
> usually do so with legal advice. Every case is different - it depends on
> what the other license terms and conditions are and what the code is and why
> the project requires it.

> If the PMC approves this, we will ensure that the legal documentation (e.g.
> the about.html for the plug-in containing this content) is correct and flows
> down the necessary terms and conditions.

> If I understand it correctly, the code Philipp would contribute to
> Eclipse.org does not in itself implement any patented invention but when
> combined with some other code there is a patent that it reads on? That
> question and likely others need to be answered first. This is not the best
> forum to discuss these types of issues so I suggest that you bring this to
> the attention of the PMC and we can work out what to do.

> Adrian

> Adrian Cho
> Manager, Intellectual Property
> IBM

> "Philipp W. Kutter" <kutter@a4m.biz> wrote in message
> news:c66o5n$tjb$1@eclipse.org...
> > Hi, Ed.
> >
> > I was already discussing this issue with my patent lawyer.
> >
> > He said, that in principle it is no problem if we open
> > the code implementing our patented-technology, but we would
> > purely rely on the patent protection. This is perfectly
> > enough for us, thus we want to open-the code.
> >
> > The question I had is whether the Eclipse project has a problem
> > if I publish code which has a licence saying:
> >
> > "You can do with this code whatever you want, except what is
> > claimed by patent XXX.
> >
> > This licence is not a licence to the technology protected by
> > patent XXX. It is therefore not allowed to use the complete
> > code as it is, since this will infringe patent XXX.
> >
> > This code can be reuse as part of any system or tool which is not
> > protected by the claims of patent XXX."
> >
> >
> >
> > I fear my lawyer cannot answer whether this is a problem for the
> > Eclipse project.
> >
> > The best what I can think of, was going again for lunch with Erich Gamma,
> > who has his office around the corner. But I wanted to meet next time with
> > him, when I can show him our EMF application ;-)
> >
> > Best, Philipp
> >
> >
> > Ed Merks wrote:
> >
> > > Philipp,
> >
> > > I'm most certainly not a legal expert and so what I have to say is
> certainly
> > > not legal advice. ;-)
> >
> > > I know that at IBM we are able to open-source patented technology, so
> this is
> > > not in and of itself a problem.
> >
> > > We've been talking to Eclipse folks about creating an Eclipse technology
> > > project where people can host their EMF models and EMF tools and
> utilities
> > for
> > > others to share, reuse, make contributions to, or derive their own
> solutions
> > > from. When we get to that point, and you are wanting to make a
> contribution,
> > > you will need to get some expert legal advice.
> >
> >
> > > "Philipp W. Kutter" wrote:
> >
> > > > We work on code where we combine one fixed Schema with an exchangable
> > > > Schema, and then we decorate the documents from the exchangable Schema
> > > > with elements comming from the fixed Schema.
> > > >
> > > > Within this, we define as well pattern-matching over documents of the
> > > > exchangable Schema. Further it contains parts representing code as
> EMF,
> > > > and doing partial evaluation and attribute grammar like things over
> > > > EMF.
> > > >
> > > > I think these parts of our code may be useful for the
> > > > community, and we plan to provide it open-source.
> > > >
> > > > Another part of our code is used to implement with this infrastructure
> a
> > > > patented technology for executable XML.
> > > >
> > > > Do you think this is a problem, if code provided for the exchange
> > > > contains parts implementing non-open technology?
> > > >
> > > > For us it is not a problem, as we have an open version of our tool,
> > > > and as we purely rely on the protection of the patent, we do not hide
> the
> > > > code. And other people may do something useful with parts of the code.
> > > >
> > > > Please let us know.
> > > >
> > > > Best Regards,
> > > > Philipp
> > > >
> > > > Nick Boldt wrote:
> > > >
> > > > > Everyone:
> > > >
> > > > > It's been suggested that it would be cool to have a place to
> > > > > discuss/share extensions and implementations that the user community
> has
> > > > > done with EMF and/or XSD... things like for example, [your project
> here].
> > > >
> > > > > If you have some input as to what you'd like to post, see, share,
> etc.,
> > > > > please reply to this thread. I'm looking to design some sort of
> > > > > community page on eclipse.org/emf and /xsd where you could both hunt
> for
> > > > > implementations/solutions/extensions and also share others. A little
> > > > > free advertising.
> > > >
> > > > > If you have anything to contribute - ideas, comments, feedback,
> whatever
> > > > > - please post it here or email me.
> > > >
> > > > > Thanks!
> > > >
> > > > > Nick Boldt :: Java Developer
> > > > > Eclipse EMF and SDO Frameworks
> > > > > codeslave@ca.ibm.com
> >
> >
Classifying Community Page Submissions (was Re: Announcement: New EMF/XSD Community Page: EMF/XSD Im [message #586219 is a reply to message #41792] Wed, 28 April 2004 19:09 Go to previous message
Nick Boldt is currently offline Nick BoldtFriend
Messages: 481
Registered: July 2009
Senior Member
Can't see any reason to exclude SDO from this community page. However,
let me ask the question:

Should SDO contributions be categorized differently than EMF
contributions? Or since SDO is a part of the larger EMF, should these
contributions simply be lumped in with the rest of the EMF stuff?

I can see benefits either way - I'm curious what the consensus is among
those who use EMF and SDO regularly, plus the general feeling re: which
would be more useful to other users/newbies to approach/use your
contributions.

Actually, that gets me into another realm where you all can assist me.
Admittedly it's a little cart-before-horse, but if you were going to
have to search thru a database of these implementations, solutions,
extensions, etc... what would be some common keywords, categories,
classifications, etc. that would allow people to either browse or search
more easily? Should the process of submitting involve provision of some
meta-information regarding this classification/categorization (a few
simple questions, along with contact info [email, website, other])?

That is - if you want to contribute - what's the best, simplest way to
both describe your submission and make it easily findable by others?

Thanks!

Nick Boldt
codeslave@ca.ibm.com


Eike Stepper wrote:
> nick and everyone,
>
> that sounds great to me. what about sdo? since persistence
> issues seem to be a major concern of many engineers i'd be
> pleased, if sdo would also be a topic there.
>
> i am currently working on a proof of concept for connecting
> an emf model to a relational database. a stable prototype
> should be ready in 2 weeks or so. i'd like to make it open
> source then and free of any license fees (ed: for my understanding
> it's a "product" nevertheless ;-))
>
> according to the special needs of my application, i formed the
> top level requirements of my persistence framework like this
> (in the following "persistence" refers to the ability of a model object
> to persist to a relational database):
>
> 1) persistence does not necessarily have to be transparent
> (a persistent class may have to extend a special base class
> or implement a certain interface).
> 2) persistence should integrate well with generated editors.
> 3) at client-side the objects shall be modifiable in the context
> of a transaction (with commit and rollback).
> 4) transactions shall use optimistic locking.
> 5) objects shall be "hot-connected" to the central repository
> (that is, they are actively invalidated by the server on change
> through one client - because of this i tend to call the framework
> CDO for "connected data objects").
> 6) network calls shall be minimized with respect to number and size,
> i.e. a CDO use case (like "load initial contents") shall result in a
> single request (as opposed to the "1+N problem" of entity EJBs
> for example).
> 7) the central store of objects shall implement a garbage collection.
> 8) the repository objects shall be queriable (SQL, OQL, ...)
> 9) of course the framework shall be convenient, stable and performant ;-)
>
> from these requirements i derived a basic system architecture:
>
> - three tiers are necessary to fulfill [Req6]. clients must not commuincate
> directly with the database, but with a CDO server instead, that takes a
> single CDO request from a client and starts chatting with the database.
> the database can even be embedded for performance reasons.
> - the protocol between client and CDO server is proprietary, because
> most of the signalling frameworks i know (like KOI) seem to implement
> the client-server paradigm (request-indication-repsonse-confirmation)
> only uni-directional. JVM, the Jet Virtual Medium could possibly be
> used: http://www.cs.purdue.edu/homes/sion/jvm/docs To fulfill [Req5]
> the paradigm has to be implemented bi-directional, that is the client
> has also to act as a server (also known as asynchronous push service).
> - the protocol is binary [Req9].
> - persistent objects have a common ancestor class [AntiReq1] which
> hosts a unique (long) id and a version int [Req4]. The common
> ancestor class makes it possible to find a track of each object in a
> single table, which is a precondition to store _all_ references to
> arbitrary objects in another single table. That, in turn, enables for a
> deterministic, ad-hoc garbage collection with a single jdbc call [Req7].
> - the base class also has an invalidation flag that is set on change
> notification of the server and triggers a reload when the object is
> used the next time [Req5]+[Req6].
> - object attributes (and only attributes) are stored in separate tables per
> inheritance level [Req8].
> - the ecore change model is used to implement client-side transactions
> [Req3]. as of now they are optimized for rollbacks. for committing
> changes the change description has to be reversed (and applied twice
> unnecessarily). since all objects own a unique id, it should be possible
> to make a change recorder that optimizes for commits, like Ed noted
> recently in this group.
> - the CDO server loads the EMF model and uses EMF reflection to
> create the mappings and tables automagically [Req9]. Later one could
> use ecore annotations to influence mappings.
> - the generated editors reflect invalidations visually (by decorating the
> respective nodes as invalid or by directly reloading them) [Req2].
> this is not achieved, yet ;-(
>
> there are many issues not covered by my current implementation, like
> support for multi-valued attributes and user data types. further
> optimizations will cover memory issues in the client (unloading of
> seldomly used objects from the model) and performance issues in the
> server (caching of prepared statements or even object data in memory).
>
> i really hope that my work could be valuable for someone else, too.
> and it would be cool, if others would review my ideas, give
> implementation tips or even help to develop and maintain the project.
>
> i have no experience with team based, open source development, yet,
> but maybe the new site, you mentioned, is a starting point for that...
>
> /eike
>
>
> "Nick Boldt" <codeslave@ca.ibm.com> schrieb im Newsbeitrag
> news:c61c8i$8qd$1@eclipse.org...
>
>>Everyone:
>>
>>It's been suggested that it would be cool to have a place to
>>discuss/share extensions and implementations that the user community has
>>done with EMF and/or XSD... things like for example, [your project here].
>>
>>If you have some input as to what you'd like to post, see, share, etc.,
>>please reply to this thread. I'm looking to design some sort of
>>community page on eclipse.org/emf and /xsd where you could both hunt for
>>implementations/solutions/extensions and also share others. A little
>>free advertising.
>>
>>If you have anything to contribute - ideas, comments, feedback, whatever
>>- please post it here or email me.
>>
>>Thanks!
>>
>>Nick Boldt :: Java Developer
>>Eclipse EMF and SDO Frameworks
>>codeslave@ca.ibm.com
>
>
>
Previous Topic:New Library for generating xml instance etc.. etc..
Next Topic:Re: EMF, SDO & XSD Update Site (was Re: EMF Update Site)
Goto Forum:
  


Current Time: Wed Oct 21 13:36:40 GMT 2020

Powered by FUDForum. Page generated in 0.02893 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top