> > [After locally modifying a plugin tiddler] I select the plugin and > > click "sync". What happens? > > You'll get a message "Changed while unplugged and on server", and > basically cannot use the automatic sync for this tiddler.
Ah but the UI still selects those tiddlers by default and when you submit, it tries to push (put) the changes but fails. > This depends on the adaptor. To detect whether a new version is > available on the server, the FileAdaptor uses the modified date, while > the TiddlyWebAdaptor uses the revision number. Okay cool. What is this revision number? Is it changecount or server.page.revision? > > And in the case of the other adaptors, is the newest version retained? > > I'm not sure I understand the question. Okay. That's too bad. Haha, what I meant was simple: FileAdaptor should do one-way "gets" while bidirectional adaptors would be expected to do both "gets" and "puts". And that would depend then on the version comparison used, always choosing the newest version to propagate changes to the older version. > That would be useful in this particular scenario (plugins), but might be > rather limiting in other scenarios (e.g. exchanging tiddlers with an > arbitrary number of parties) - i.e. plugin territory? Plugin territory? Explain yourself. Yeah I know that it is a specific use case (plugins) but it is a use case that extends to every kind of "supply scenario." That is, plugin repositories, package repositories. They would want this. It would only be an option. The "authoritative" flag would be cleared upon importation. But it would be enough if the FileAdaptor would recognize that it couldn't do "puts" and would simply acknowledge that it "cannot update remote". > Well, that's kind of what's happening - it's "just" that the UI-level > reporting is rather poor. Code contributions on that front would be most > welcome. Okay I'll keep it in mind. Busy with other things now tho. > > It would also be helpful if the mechanism would take account of > > tiddler::Version slices when present on tiddlers both local and > > remote. > > We've had similar discussions in the past (might be worth searching the > [twdev] archives) - but IIRC, the complexity proved overwhelming (as is > the nature of synchronization), especially as there are no standards > (only conventions) around plugin metadata. Right. I know. I was doing an internship assignment once about the development of an LDAP plugin for a document management system, that would then serve as the backend for the document store, complete with import and export facilities at the administrator level. It was horrible. Well, I think I know enough for the documentation now, for the present moment. Thanks :). -- You received this message because you are subscribed to the Google Groups "TiddlyWiki" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/tiddlywiki?hl=en.
