Hello Patrick,

On May 14, 2010, at 19:56 , Patrick Ohly wrote:

> On Fri, 2010-05-14 at 17:28 +0100, Lukas Zeller wrote:
>> Hello Patrick,
>> 
>> I think by far the simplest method would be NOT to try to bypass
>> MultifieldItem, but derive it with an implementation that puts/gets
>> data (and maybe metadata) into/from well-known string or BLOB fields.
>> 
>> The entire DB API thing was developed long after we more or less
>> settled for TMultiFieldItem as a common denomiantor for all data
>> types.
> 
> Yeah, I noticed. I have a sync starting based on the TSimpleItem and the
> string-based API, but now I run into more places where a TMultiFieldItem
> is expected, like for example in customimplds.cpp:
> 
> 3118    // - create dummy item
> 3119    TStatusCommand dummy(getSession());
> 3120    TMultiFieldItem *delitemP =
> 3121      static_cast<TMultiFieldItem *>(newItemForRemote(ity_multifield));
> 3122    delitemP->setSyncOp(sop_delete);
> 3123    PDEBUGPRINTFX(DBG_DATA,(
> 3124      "Zapping datastore: deleting %ld items from database",
> 3125      (long)fSyncSetList.size()

Yes, customimplds.cpp already makes assumptions. It's not totally generic in 
the original concept of the engine; that's where it's name comes from, it means 
something like "customisable datastore" and was implemented for multifield 
items only. The original concept did not make any assumptions about what an 
item would be.

>> The TField mechanism has proven so useful in various contexts, like
>> the API itself, but also for scripting etc. that while deriving from
>> beyond TMultiFieldItem would still be possible, I see no benefit (and
>> a lot of drawbacks) actually doing so.
> 
> Initializing a TMultiFieldItem(Type) seemed more complex than necessary,
> but I agree, it probably is easier to set it up right and just use it.
> 
>> If it's of any help for you, I could offer to add such a thing real soon 
>> (this weekend?).
> 
> That would be a big help. I'm fairly confident that I would get it done
> myself (in particular after having spent some time with the code),

No doubt!

> but there might be snags that'll delay me that you know how to avoid.

That's why I offer it - I often automatically get an uneasy feeling when I'm 
about to do something wrong, simply because it rings a faint bell of dead-ends 
I encountered (and created) myself long time ago :-) That saves some time.

> My goal was to have something rudimentary next Monday, so if it is not
> too much bother for you, then I'll punt the problem to you.

So let's hack :-)

I'll see that I have something for you to test this weekend (on a simpletype 
branch).

Lukas Zeller (l...@synthesis.ch)
- 
Synthesis AG, SyncML Solutions  & Sustainable Software Concepts
i...@synthesis.ch, http://www.synthesis.ch





_______________________________________________
os-libsynthesis mailing list
os-libsynthesis@synthesis.ch
http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis

Reply via email to