Hi Kristina,
It sound like MKS is similar to JIRA, in that it relies on a large
number of predefined queries either available to everyone or per user account.
Our JIRA Connector supports this by allowing the user to select a predefined
query on the server and add that to the Task List, in addition to supporting custom
query creation from within Eclipse:

So this should be straightforward to do by using a similar approach to
JIRA. If we have two clients doing this we can make it a generic facility
in the Tasks Framework as has been requested:
155487: add generic support for retrieving saved queries
https://bugs.eclipse.org/bugs/show_bug.cgi?id=155487
Great to hear that there is complementary overlap between Mylar’s
Tasks Framework and your integration needs. We can discuss generic
connector needs further here, but I’ll also respond on the corresponding
bug report.
Also note that in terms of adopting these APIs it is best that you wait
until after the 1.0 release which is scheduled to be announced on December 11th
(contingent on the final steps of the corresponding eclipse.org IP approval
process).
Mik
> -----Original Message-----
> From: mylar-dev-bounces@xxxxxxxxxxx
[mailto:mylar-dev-bounces@xxxxxxxxxxx]
> On Behalf Of Kristina
Taylor
> Sent: Wednesday, November 15, 2006 1:53 PM
> To: Mylar
developer discussions
> Subject: RE: [mylar-dev] Bug 160928: [connector] MKS Integrity
>
> I've attached several screenshots of the MKS Worktray
and the Web UI to
> the bug. I hope those help to give an idea of how things
work on our
> end of things.
>
> It seems as though the generic web connection works well, and we
can
> probably get away with using the web interface for editing and
creating
> tasks (I'm going to adopt your "task" terminology from
hereon, just to
> make things easier). That may even work more smoothly than
what we have
> in our current integration. We currently have no real
offline support
> for tasks, so this would be a benefit to integrating with mylar as
well.
> I'm under the impression that the majority of our users are
unfamiliar
> with the MKS
Worktray aspect of our integration
(it's very well hidden),
> and mostly use the source repository end of things, so removing
the MKS
> Worktray completely and adding any missing functionality somewhere
else
> (we also have a change package management view) wouldn't be the
end of
> the world.
>
> How do queries work with Mylar? Can the connector be
designed so that
> you retrieve a list of queries from the server, then have the list
of
> visible tasks be based on the currently active query? Our
software
> allows users to save queries, which are later available to
themselves or
> other groups of users. I currently have 480 queries
available to me,
> and rebuilding even a small portion of those to be able to
retrieve
> relevant groups of tasks would be a huge pain. Users of MKS
Integrity
> will only ever see a list of tasks as returned by some query (or a
text
> search), though you can view individual tasks directly. We
do our
> degree-of-interest in tasks based on queries, whereas (from my
> understanding) your software does degree-of-interest in the code
base
> based on active tasks. Combine the two, and you have a
killer
> productivity app, which only lets you see what's currently
relevant. :)
>
> Thanks for your input,
> Kristina
Taylor
>
> -----Original Message-----
> From: mylar-dev-bounces@xxxxxxxxxxx
> [mailto:mylar-dev-bounces@xxxxxxxxxxx] On Behalf Of Mik Kersten
> Sent: Wednesday, November 15, 2006 1:39 PM
> To: 'Mylar developer discussions'
> Subject: RE: [mylar-dev] Bug 160928: [connector] MKS Integrity
>
> Hi Kristina,
>
> Great to hear that you're interested in integrating with Mylar.
>
> > -----Original Message-----
> > From: mylar-dev-bounces@xxxxxxxxxxx
> > [mailto:mylar-dev-bounces@xxxxxxxxxxx]
> > On Behalf Of Kristina
Taylor
>
> > Now, all that being said, I have some questions:
> > 1) Does the integration need to be released as a part of your
product,
>
> > or can it be part of our existing eclipse integration?
>
> I think that it would be best to release this integration as part
of
> your Eclipse integration, since it is targeted at the MKS user
> community. What we could do on our end is link it from our
site and
> make sure that it's easy to install for new Mylar users who are on
MKS.
>
> > 2) We currently have our own version of an Eclipse Task list,
called
> > "MKS
Worktray". It has the
ability to create new issues, edit issues,
> > run a query, and deal with change packages. How
much of this
> > functionality would we be able to integrate via "rich
editing"? Can
> > Mylar connectors be organized so that our UI would be called
when a
> > user tries to edit a task?
>
> Could you send some screenshots of the MKS Worktray
in action? That
> would give me a better sense of how best to approach the
integration.
> The Mylar Task List has a considerable amount of functionality
that is
> related to rich editing. For example, it shows notifications
of
> incoming changes, and indicates when a query synchronization
failed. It
> is also the anchor for managing the offline support, since only
the
> tasks that the user has read are stored offline, only changes
tasks are
> synchronized, and all of this state is maintained in the
TaskList. Now,
> we do have a loosely-coupled architecture so you could actually
use the
> TaskList (in ..mylar.tasks.core) without using any of the UI stuff
or
> having your users install it, but we would need to figure out how
much
> of the UI stuff you would need to duplicate for MKS Worktray,
and
> whether it is easier for you to extend or integrate with Mylar's
Task
> List.
>
> One thing to consider when deciding whether to integrate with or
to
> replace the functionality of the Task List is whether your
developers
> will want the Task List anyway. In our experience developers
work with
> three kinds of
> tasks:
> * The issues and tasks that make up their project (i.e. in MKS
> integrity).
> * Bug reports and enhancement requests that they watch and create
for
> the other frameworks that they use (e.g. bugs against Eclipse,
JEE,
> Spring).
> * Personal tasks and todos they need to make for themselves (via
Mylar's
> Task List).
>
> For this reason a fundamental part of our approach is to give
developers
> a single view for managing all of their tasks, and to make it easy
for
> vendors to customize the content of the Task List and rich editors
to
> meet their needs (e.g. as JIRA does with custom task icon type
> overlays). This is discussed some in the following article:
>
> http://www-128.ibm.com/developerworks/java/library/j-mylar1/
>
> The other thing to consider is integration with Mylar's automatic
> context management facilities. Again, this is possible to
integrate
> with a custom view, but the Task List has been streamlined around
the
> interaction needed to make task activation easy. More on
that is here:
>
> http://www-128.ibm.com/developerworks/java/library/j-mylar2/
>
> > 3) What level of effort (# of developer days) do you think
would be
> > required for a reasonably proficient Java developer already
familiar
> > with Eclipse?
>
> Integrating MKS queries either via a web connector template or via
a
> customized connector should not be much work, a week at
most. The
> amount of work for the rich and offline editing we would need to
figure
> out the integration strategy wrt to question (2) above (e.g. if it
> involves re-implementing rather than extending substantial parts
of the
> Task List it
> could be quite a bit of work since the ..mylar.tasks.ui is 25
KLOC).
>
> Mik
>
> --
> Mik
Kersten, http://kerstens.org/mik
> Mylar Project Lead, http://eclipse.org/mylar
>
>
> _______________________________________________
> mylar-dev mailing list
> mylar-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/mylar-dev
> _______________________________________________
> mylar-dev mailing list
> mylar-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/mylar-dev