xmlformat future

Hi all,

I have just hit bug #923 [1], which seems to be blocking syncing of events in
the Opie plugin. The ticket appears to have been closed due to xmlformat being
split out. but the problem is still there so surely the bug should remain
open?

As far as I am aware, we have not had a clarification as to the future of
xmlformat. The Opie plugin relies heavily on xmlformat and would require a
major rewrite if it had to use something else.

What is the plan here?

Thanks,
Paul

[1] http://www.opensync.org/ticket/923

------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________
Opensync-devel mailing list
Opensync-devel@...
https://lists.sourceforge.net/lists/listinfo/opensync-devel

[Daniel Gollub-2]

On Saturday 21 March 2009 05:27:09 pm Paul Eggleton wrote:
> Hi all,
>
> I have just hit bug #923 [1], which seems to be blocking syncing of events
> in the Opie plugin. The ticket appears to have been closed due to xmlformat
> being split out. but the problem is still there so surely the bug should
> remain open?

I reopened the ticket and moved it to the xmlformat 0.40 milestone.
The reason i closed it last time was due the ongoing discussion if we should
release xmlformat plugin with 0.40 or not. Since this changed again and the
issue still seems to be present i reopened the ticket.

>
> As far as I am aware, we have not had a clarification as to the future of
> xmlformat. The Opie plugin relies heavily on xmlformat and would require a
> major rewrite if it had to use something else.
>
> What is the plan here?


We stay with the xmlformat plugin until there is an alternative format plugin
which we could use as common format plugin - which is from qualtiy way better
then the xmlformat plugin and only if it brings really benefit to port to it.
Even then i guess will provide some conversion code from xmlformat to the new
format as mid term solution.

So keep going with xmlformat plugin.


> [1] http://www.opensync.org/ticket/923

Best Regards,
Daniel

------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________
Opensync-devel mailing list
Opensync-devel@...
https://lists.sourceforge.net/lists/listinfo/opensync-devel

On Wednesday 25 March 2009, Daniel Gollub wrote:
> We stay with the xmlformat plugin until there is an alternative format
> plugin which we could use as common format plugin - which is from qualtiy
> way better then the xmlformat plugin and only if it brings really benefit
> to port to it. Even then i guess will provide some conversion code from
> xmlformat to the new format as mid term solution.
>
> So keep going with xmlformat plugin.

OK, thanks for the clarification.

Cheers,
Paul

------------------------------------------------------------------------------
_______________________________________________
Opensync-devel mailing list
Opensync-devel@...
https://lists.sourceforge.net/lists/listinfo/opensync-devel