Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [mylar-dev] task list externalization 
Eugene,
While I think your idea is a reasonable one, I don't think that this should make it into 1.0 like you suggested it needed to be. If my memory serves, RC2 is scheduled to go out within the next day or two, which IMHO doesn't leave us enough time to stabilize this new API.
I think it would be a good idea to make this change when we revisit Bug 150680: Generalize repository configuration persistance and move into tasklist 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=150680

regards,
Nathan

Eugene Kuleshov wrote:

Steffen Pingel wrote:
I don't think it is a good idea to replace a well known API (w3c) with a custom interface that almost remodels that API. It imposes additional overhead for implementors who need to learn a new API.
In most cases user have to write only few methods, and IElement provides very simple type-safe abstraction for the hierarchical data structures while w3c API imply very specific physical and in-memory representation. On top of that w3c API is not type safe and I haven't seen many developers who really enjoy w3c API.
Another advantage is that we can easily change physical representation or even don't use XML underneath and externalisers won't have to know about it. For example, to change layout from current: 

 <customElement customAttr="value"...

 to more more normalized variant like
<element name="customElement"><attribute name="customAttr" value="value"... 

 will be just a matter providing an appropriate IElement implementation.
With that API I can also see how to hook up database or lucene-based storage for the task list still without need to change externalizers. 

 The more I look at this, the more I like it. :-)
Unless there are hard facts (could you use TPTP to collect a few numbers?) that this approach yields a significantly better performance I'd rather keep the current implementation.
As I already mentioned, subjectively performance is not much better. But I suspect that memory footprint at saving should be less. Anyways, I don't think TPTP is currently support Eclipse 3.3 which I am usung here.
I suppose close() writes the node to the stream?
Not quite. Element is written to stream directly when addAttribute(), addChildElement(), etc methods are called. So, close() just writing closing xml tag and in a sense it is the same as adding this element to the parent's children. Basically entire data structure is not held in memory during externalizing. The xml for my current task list is over 3Mb and only God knows how much it really when this thing is represented as w3c DOM.
For a stream-based implementation I'd expect an API closer to Java serialization: 

 public readQueryHit(NodeInputStream in, TaskList taskList, ...);

 public interface NodeInputStream  {
     Node readNode();
 }
How that is different from API I suggested, except that user already receive node instance.
public AbstractQueryHit readQueryHit(IElement node, TaskList taskList, ...);
I was too lazy to implement SAX or StAX variants for IElement, but it should be possible.
Also note that I was able to remove need to iterate trough query hits or subtasks on the externalizeres. All task list composition is done by the TaskListWriter class 

 regards,
 Eugene


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

Back to the top