Coming changes in e4Graph APIs 
Author Message
 Coming changes in e4Graph APIs

I wanted everyone to have an opportunity to have a say in this
discussion, so that I can make the right decision. I'm posting this
here because e4Graph has a widely used Tcl binding, so I should ask
my Tcl users for input :).

The background is that I'm finding the current terminology of e4graph
hard to explain and understand, and non-standard as far as graph theory
goes. So the following changes are intended to make the APIs more
conformant to the common terminology as well as making e4Graph richer,
more capable and easier to understand. I want to make the changes *now*,
before e4Graph 1.0final comes out, so I will not have to support two
very different APIs forever.

Some of you may know already that e4Graph is a way to store arbitrary
directed graphs of objects in persistent storages. I use Metakit as the
storage mechanism, with great success -- Metakit has been extremely
robust, fast, portable and useful, and besides, it's supported by the
world's most responsive programmer, JCW :). e4Graph has language
bindings for Tcl and Java, and now python is being added. I'm also
planning to make e4Graph use other DBs as storage, e.g. mySQL,
postgress, etc.

e4Graph currently has just two concepts, nodes and vertices. Nodes are
ordered collections of vertices, and vertices are a mechanism to
transition from a node to a value (be it an integer, double, string,
binary or other node). You'll note that the terminology is not
graph-theory-standard; usually what e4Graph calls vertice is called edge
in graph-theoretic terminology.

The new e4Graph API will be based on three concepts (instead of the
existing two):

* Nodes stay the same.
* Vertices that lead from a node to another node are now edges.
* Vertices whose value is a scalar, string or binary are now attributes.
An attribute is simply an association between a string name and a typed
value. In the new API, attributes can have *anything* as their value,
including scalars, string, binary, edge or node.

Nodes thus now become ordered collections of edges. Additionally, edges
and nodes can have any number of attributes. Previously verices were
named. The name now becomes one of the attributes on the equivalent edge.

All of this implies large changes in the APIs of all language bindings.
I formally can do this now, because e4Graph is still in Alpha (and I
kept it in Alpha for a very long time for the express purpose of getting
everything right the first time). However, I recognize that many
projects already use e4Graph, some commercially. Therefore I solicit
feedback.

Two alternatives, besides making the changes now:

* The first is to bring e4Graph 1.0 to the release version with the
current API and then immediately abandon it. New development will go
into e4Graph 2.0 which will be finished much faster than 1.0 was.
* Not make any changes, ever. e4Graph 1.0 is the only version, and we
live with the non-standard terminology and without the flexibility
afforded by the new attribute mechanism.

As might be obvious, I prefer the proposal I'm making here, and as a
less desirable alternative, to finish 1.0 and move on immediately to 2.0
while supporting 1.0 with bug fixes (but NO NEW DEVELOPMENT).

Please send in your comments. I will wait for a couple of weeks before
deciding anything.

--JYL



Sun, 30 Oct 2005 23:46:45 GMT  
 Coming changes in e4Graph APIs

Quote:

> I wanted everyone to have an opportunity to have a say in this
> discussion, so that I can make the right decision. I'm posting this
> here because e4Graph has a widely used Tcl binding, so I should ask
> my Tcl users for input :).

As a proto user -- I have alpha code which uses your alpha code :-) -- I
find your suggested  new API more natural than the earlier one. I was a
little confused by the earlier version.

Steve



Mon, 31 Oct 2005 08:51:33 GMT  
 Coming changes in e4Graph APIs
This looks interesting -- how about some screen shots of what you can
do with this package?

We ahve developed our own graphing solution based on core Tcl/Tk.  But
it's performance is not as robust as it should be.  I would like to
see what this can do. - Also does it work on a mac?

Dave



Mon, 31 Oct 2005 21:44:20 GMT  
 Coming changes in e4Graph APIs
It's a graph manipulation package, with persistence, not a graph display
package. So sorry, no screen shots.

It *should* work on MacOS X 10, in fact I'm working on making it work on
the compile farm at sourceforge.net, and we'll see whether the next
Alpha will officially support MAcOS X 10. Earlier MacOS versions are not
going to be supported, sorry. If you do succeed in making it work there,
great.

Performance is probably going to be better than pure Tcl code, and you
get support for persistence for free.

--JYL

Quote:

> This looks interesting -- how about some screen shots of what you can
> do with this package?

> We ahve developed our own graphing solution based on core Tcl/Tk.  But
> it's performance is not as robust as it should be.  I would like to
> see what this can do. - Also does it work on a mac?

> Dave



Mon, 31 Oct 2005 22:15:57 GMT  
 Coming changes in e4Graph APIs

Quote:

> It's a graph manipulation package, with persistence, not a graph display
> package. So sorry, no screen shots.

What is the difference between a "graph manipulation" package and a
"graph display" package?

Dave



Tue, 01 Nov 2005 13:28:33 GMT  
 Coming changes in e4Graph APIs
I don't do layout on a Tk widget. That's display. I mean manipulation in
the sense that you can change the structure of the graph via Tcl (and
other language bindings') commands.

--JYL

Quote:


>>It's a graph manipulation package, with persistence, not a graph display
>>package. So sorry, no screen shots.

> What is the difference between a "graph manipulation" package and a
> "graph display" package?

> Dave



Tue, 01 Nov 2005 14:07:49 GMT  
 Coming changes in e4Graph APIs

Quote:


>>It's a graph manipulation package, with persistence, not a graph display
>>package. So sorry, no screen shots.
> What is the difference between a "graph manipulation" package and a
> "graph display" package?

One is pretty, the other just takes memory.  ;)

--
     Jeff Hobbs                     The Tcl Guy
     Senior Developer               http://www.ActiveState.com/
         Tcl Support and Productivity Solutions



Tue, 01 Nov 2005 14:15:23 GMT  
 Coming changes in e4Graph APIs

Quote:

> I wanted everyone to have an opportunity to have a say in this
> discussion, so that I can make the right decision. I'm posting this
> here because e4Graph has a widely used Tcl binding, so I should ask
> my Tcl users for input :).

I've only played around with e4graph a little - but have a project where
I plan to use it.
 From the outset I found the word vertice in that context confusing.
I vote for 'edges' as soon as possible.
I'd prefer an interim release version with the updated terminology but
as little in the way of entirely 'new' features as possible, but maybe
some docs on what's planned.
I don't quite understand why attributes should contain nodes & edges...
seems like an invitation to short-circuit the graph mechanism.
What's wrong with using edges for all such relations and tagging the
edges with a type attribute if you need to keep them separate in some sense?
Sounds like an unnecessary complication to me that violates the unity of
the thing .. can you give an example of why one might use an attribute
containing a node? Is it somehow more 'lightweight' than an edge?

Julian



Tue, 01 Nov 2005 15:53:40 GMT  
 Coming changes in e4Graph APIs
Julian

Thanks for the comments and great that you intend to use e4Graph. Also
thanks for asking this edge vs attribute question. The reason I propose
this is that graph theory allows it, and I want to be as conformant as
possible. For an example of a similar system, check out graphviz
(http://www.graphviz.org/) which has the same (or very very similar)
terminology I propose and also as far as I can tell the set of allowed
value types for attributes contains edges and nodes there.

For my money, this *does* add a whole host of complications to the
implementation and adds very little in terms of functionality. I'd be
very happy to limit attributes to contain only scalars, strings and
binary data as values.

--JYL

Quote:


>> I wanted everyone to have an opportunity to have a say in this
>> discussion, so that I can make the right decision. I'm posting this
>> here because e4Graph has a widely used Tcl binding, so I should ask
>> my Tcl users for input :).

> I've only played around with e4graph a little - but have a project where
> I plan to use it.
>  From the outset I found the word vertice in that context confusing.
> I vote for 'edges' as soon as possible.
> I'd prefer an interim release version with the updated terminology but
> as little in the way of entirely 'new' features as possible, but maybe
> some docs on what's planned.
> I don't quite understand why attributes should contain nodes & edges...
> seems like an invitation to short-circuit the graph mechanism.
> What's wrong with using edges for all such relations and tagging the
> edges with a type attribute if you need to keep them separate in some
> sense?
> Sounds like an unnecessary complication to me that violates the unity of
> the thing .. can you give an example of why one might use an attribute
> containing a node? Is it somehow more 'lightweight' than an edge?

> Julian



Tue, 01 Nov 2005 17:45:12 GMT  
 Coming changes in e4Graph APIs
I guess I can understand the temptation to allow edges to have
attributes pointing to nodes - so that for example you could have
metadata about your main graph that is itself a graph.
I just think that you could achieve the same thing with a little bit of
syntactic-sugar/help from the API (though not necessary; could be
layered on by the app)- but keeping the allowable structure strictly
node<->edge.
I mean.. if you allow an attribute to point to a node, next you'll have
someone complaining that they can't navigate from the node to some
far-off-elsewhere-in-the-graph attribute that points to it.. so then
they'll want an attribute on the node pointing back to that attribute or
else some other way of making it bidirectional and your attribute is
starting to morph into a node or edge anyway isn't it?

I think it'd be nice if you could somehow specify that you are walking
the graph in a particular 'context' (or list of contexts) and thus
ignore/follow relevant/irrelevant edges that represent connections to
'other' graphs/sub-graphs/meta-graphs. Perhaps the API could be aware of
'graph-context' attributes and simply provide for more efficient means
of checking/ignoring these than the application developer could by
wrapping it up themself.

It may at first seem clumsy to have say an edge linked to a foreign node
by having the edges own two nodes both link to it in the normal fashion
but with some describing attributes - but I think it keeps the
underlying nature of it simpler and more elegant.

It also seems intuitively possible to me that some form of hypergraph
(one node in effect pointing to a set of nodes) could be implemented on
top of the existing structure.

I'm not particularly fluent with the mathematical theory behind graphs -
  so I may have missed some valid reason why you'd allow these
nonstandard links, but I couldn't find anything mentioning the
allowability or otherwise of such extended attributes. Do you happen to
have a pointer to something that more directly mentions it?

Cheers,
Julian

Quote:

> Julian

> Thanks for the comments and great that you intend to use e4Graph. Also
> thanks for asking this edge vs attribute question. The reason I propose
> this is that graph theory allows it, and I want to be as conformant as
> possible. For an example of a similar system, check out graphviz
> (http://www.graphviz.org/) which has the same (or very very similar)
> terminology I propose and also as far as I can tell the set of allowed
> value types for attributes contains edges and nodes there.

> For my money, this *does* add a whole host of complications to the
> implementation and adds very little in terms of functionality. I'd be
> very happy to limit attributes to contain only scalars, strings and
> binary data as values.

> --JYL



>>> I wanted everyone to have an opportunity to have a say in this
>>> discussion, so that I can make the right decision. I'm posting this
>>> here because e4Graph has a widely used Tcl binding, so I should ask
>>> my Tcl users for input :).

>> I've only played around with e4graph a little - but have a project
>> where I plan to use it.
>>  From the outset I found the word vertice in that context confusing.
>> I vote for 'edges' as soon as possible.
>> I'd prefer an interim release version with the updated terminology but
>> as little in the way of entirely 'new' features as possible, but maybe
>> some docs on what's planned.
>> I don't quite understand why attributes should contain nodes &
>> edges... seems like an invitation to short-circuit the graph mechanism.
>> What's wrong with using edges for all such relations and tagging the
>> edges with a type attribute if you need to keep them separate in some
>> sense?
>> Sounds like an unnecessary complication to me that violates the unity
>> of the thing .. can you give an example of why one might use an
>> attribute containing a node? Is it somehow more 'lightweight' than an
>> edge?

>> Julian



Tue, 01 Nov 2005 20:28:31 GMT  
 
 [ 10 post ] 

 Relevant Pages 

1. OS/400 REXX - changing variables via API's

2. C API: Change immutable objects? :-o

3. RFC: Changes to the tcllib ftp package APIs for Get, Put, and Append

4. A suggestion for handling modifications in the core that change the script API

5. e4Graph 1.0a8 released

6. e4Graph 1.0a11

7. e4Graph 1.0a8 released

8. ANNOUNCE: baytug@e4graph.com

9. e4Graph 1.0a7 released

10. e4graph 1.0a7 release candidate

11. e4Graph 1.0a6

12. e4Graph 1.0a5

 

 
Powered by phpBB® Forum Software