bundle / content api redesign
Jay Shaughnessy
jshaughn at redhat.com
Tue Feb 5 15:34:15 UTC 2013
Ignore my previous reply, it was supposed to be off-list. Obviously I
don't know how to use e-mail... Anyway, an actual reply is coming...
On 2/5/2013 10:15 AM, Jay Shaughnessy wrote:
> Off-List
>
> On 2/5/2013 7:02 AM, Lukas Krejci wrote:
>> Yes, this needs to be well discussed and I appreciate your comments
>> and the time you're putting into deciphering my tangled thoughts ;)
>>
>> Before we go into the details on a call, I'd like to clear up the
>> feeling you both seem to have gotten from the wiki page.
>>
>> So far I've been dealing with the storage of the new system. To be
>> frank, the storage of bundles is a hack and is duck-taped on to the the
> I'm sorry, but I take offense to the repeated use of the word "hack"
> with respect to the Bundle data model. It was actually the result of
> many revisions, with input from many parties, and an evolving set of
> requirements. I agree that all that revision may have been somewhat
> detrimental to the finished product but it is far from a mess. It's
> actually a clear separation of the storage model and the deployment
> model.
>
> Anyway, I'll write more On-list.
>
>> content system storage and that's why I chose content storage
>> nomenclature over the bundle one (and I'd repeat - nomenclature, not
>> the semantics). But that does NOT mean I want to deprecate bundle
>> functionality. I'd say I'm doing quite a reverse. If you look at the
>> new classes like PackageDestination, they closely mimick what bundle
>> subsystem does and that is on purpose - I want to maintain the
>> workflows of the bundle subsystem (even if I use different names for
>> things) while also clearing up the domain model of the whole thing.
>> So while some core concepts of the content subsystem stay - like
>> PackageType and Package - they stay there because they are a) used by
>> the bundle subsystem today, too, and b) because they fit well into
>> the overall scheme.
>>
>> I think one more aspect was important to me when I created this - the
>> bundle subsystem is using the content subsystem for storage so
>> ripping the content domain classes from under the bundles would,
>> IMHO, be a more complex refactoring than doing the way I did. The
>> content classes stay (even if only by name) and are enhanced and the
>> bundle classes still can use these guys without us having to do
>> semantic somersaults in our heads whenever we need to talk about the
>> "old and new" at the same time.
>>
>> But overall I am not too fussed about the naming. If you think we
>> should stick with the bundle naming but you like the overall idea of
>> the unified model then I am the happiest guy in the world - it would
>> be the first time my design would stand your scrutiny :)
>>
>> Lukas
>>
>> ----- Original Message -----
>>> From: "John Mazzitelli" <mazz at redhat.com>
>>> To: "rhq-devel" <rhq-devel at lists.fedorahosted.org>
>>> Sent: Monday, February 4, 2013 9:42:20 PM
>>> Subject: bundle / content api redesign
>>>
>>> (This is more for Lukas, but it seems appropriate to discuss over the
>>> rhq-devel ML)
>>>
>>> Lukas,
>>>
>>> Jay and I went through the Bundles vs. Content design page,
>>>
>>> https://docs.jboss.org/author/display/RHQ/Bundles+vs.+Content+-+On+Its+Head
>>>
>>>
>>> In general the ideas sound good.
>>>
>>> However, there are two things I'm questioning:
>>>
>>> 1) this is a major re-design/re-implementation - I'm not sure if we
>>> need to be concerned with backward compatibility with the older
>>> content API (i.e. I think we should release this in RHQ 5 timeframe,
>>> the new major release should indicate it contains some backward
>>> incompatible changes with RHQ 4).
>>>
>>> 2) (this is the bigger concern), it seems like you deferred to
>>> maintaining the Content/Package API and deprecated the Bundle API.
>>> In my opinion, we should do this in reverse. We should maintain the
>>> Bundle API (merging in the Content/Package API where applicable) and
>>> deprecate the Content/Package API.
>>>
>>> Bundles has been a successful feature - more people are using it and
>>> like it (and they are using it successfully for things we didn't
>>> anticipate) compared to the Content/Package API (few people use it,
>>> and fewer like it :-)
>>>
>>> The Content/Package classes are what needs to be deprecated, not the
>>> Bundle classes. I would recommend that where you say things like:
>>>
>>> Bundle
>>> @Deprecated NON_ENTITY computed from Package
>>> ...
>>> BundleVersion
>>> @Deprecated NON_ENTITY computed from PackageVersion
>>>
>>> should instead be flipped like:
>>>
>>> Package
>>> @Deprecated NON_ENTITY computed from Bundle
>>> ...
>>> PackageVersion
>>> @Deprecated NON_ENTITY computed from BundleVersion
>>>
>>>
>>> and things like:
>>>
>>> PackageVersionDeployment NEW CLASS
>>> exact copy of BundleDeployment, which become @Deprecated
>>> NON_ENTITY
>>> ...
>>> PackageDestination NEW CLASS
>>> copy of BundleDestination, which becomes @Deprecated NON_ENTITY
>>>
>>> should instead just use the Bundle classes (BundleDeployment,
>>> BundleDestination) and just add data fields to the entities as
>>> necessary.
>>>
>>> We can discuss further as to why Content/Package API is being
>>> retained and Bundle API is being deprecated, but those are my
>>> immediately thoughts.
>>> _______________________________________________
>>> rhq-devel mailing list
>>> rhq-devel at lists.fedorahosted.org
>>> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
>>>
>> _______________________________________________
>> rhq-devel mailing list
>> rhq-devel at lists.fedorahosted.org
>> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
>
> _______________________________________________
> rhq-devel mailing list
> rhq-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
More information about the rhq-devel
mailing list