5:37 p.m.
On Mar 19, 2015, at 4:52 PM, Keith Babo <kbabo(a)redhat.com
<mailto:kbabo@redhat.com>> wrote:
>
>> On Mar 19, 2015, at 5:07 PM, Johnny Verhaeg <verhaeg(a)icloud.com
<mailto:verhaeg@icloud.com>> wrote
>>
>> Why are those gotchas? It still sounds like what I suggested about merging the
custom data formats with our known ones would still work and no extra fields would be
needed. What am I missing?
>
> How would you know what custom data formats to merge ahead of time? Let’s say the
user creates a custom XYZDataFormat for a proprietary XYZ format that they use. There’s
no way for us to know about this format.
I guess I thought the XYZDataFormat named would be already specified in the Camel
configure, and thus queriable. Not so?
Ah, now I see where you are going with this line of thought. Would work in some cases,
but there are cases where a data format can be registered programmatically, where this
would not be the case. Still, I think this is an idea worth thinking about in addition to
supporting “Other”.
> Even for existing data formats, the requirements may go beyond just pointing at a
file, especially if the file is an instance document and the configuration supplies
details on how that instance document is used to generate model classes and/or configure
the data format itself.
This seems way too ambitious to me. I thought you indicated the models would already have
been generated in the custom case?
They will. I was talking about cases where we support a data format as a first-class
citizen (like JSON, XML, XSD today). Concrete example: we don’t support CSV right now.
At first, we will just support it via this “Other” type support. That means the user
created the data format and generated the model classes ahead of time. In a future
milestone, we will consider adding CSV support directly to our tooling. When we do that,
we will add support for generating the models from the tooling (just for CSV) and
configuring the data format.
How could we possibly know how to generate models from within the
wizard based upon completely data format-specific configuration that we'd have no idea
how to interpret?
We wouldn’t.
Or are you envisioning specific types of custom configuration to
support?
Yep, this. I think we just crossed wires on the above. We generate models and provide
specific configuration options for the data types we directly support. For the “other”
type, we assume the model classes are already available and the user has created the data
format configuration already. All we do in our tooling is point to an existing class and
data format id.
regards,
keith
>
> ~ keith
>