Hey Eric,
Eric Barroca wrote:
> Hi Martijn,
>
> On May 19, 2005, at 6:30 PM, Martijn Faassen wrote:
[snip]
> So the
> map does not contains which features are needed, but which software
> component we imagine to need to build the platform. It could be
> changed, and I think your points are important, it's just that the map
> wasn't written as a feature map. That also why I've said that from my
> point of view metadata are covered by SchemaEngine (which, for sure,
> should have the metadata abstraction). Same for document : I think that
> DocumentEngine + SchemaEngine should manage all document type in the
> right way.
I think you're going to find problems seeing where 'implementation
stuff' crosses over into 'feature stuff'. I think a metadata engine is
implementation stuff and a schema engine doesn't cover it completely.
Anyway, I think this kind of thinking right now ("this is a feature, not
implementation related, so we don't include it") is fairly arbitrary at
this stage, and it's certainly confusing me.
What's a document engine?
>> Concerning concepts which are used to to support other facilities, I see
>> on the map that this happens too -- a storage is used to support a
>> repository for instance, but the repository is still on the map and not
>> said to not exist in the 'core framework' as it's all just about storage
>> anyway. But I do not see yet how this is different from using a schema
>> system to build a metadata framework, for instance.
>>
> Maybe because I don't really see what a metadata framework provide ? :-)
As I sketched out, a way to assign metadata sets to objects, a way to
import/export this information, possibly support for evolving metadata
sets, a tie in to indexing facilities for particular metadata fields,
support for acquiring metadata from 'higher up' such as we have in
Silva, automatic filling in of metadata values based on other
information in the system, an API to access individual metadata values,
support for particular common metadata sets, etc. None of these things
as far as I can see is clearly covered by 'schema'.
> If you think it's a component, feel free to add it. If you think that
> store/repository is like schemas/metadata framework, it has to be inside.
My whole point is that just because you can't see how it needs any
abstractions beyond what is on the map already doesn't mean that
everybody else can see the same thing. We need to have these in scope,
on some map somewhere, to be able to have a common point of reference.
This way we can determine how much work they need in the first place,
and what the implementation consequences might be.
> I think we should also start document on bit part of what is needed, to
> explain the components / features listed (like what is a component
> framework, so that we can work a bit on use cases / tech specs.
>> I am not sure we should be deciding what is in the 'core framework'
>> or not yet, or perhaps ever (though we should consider "core
>> distribution"). I am more thinking in terms of building a cloud of
>> services, so what is core and what isn't should be relatively fluid.
>> It depends on what people want to work on, after all.
> Of course we can't decide what has to be in the core framework right
> now. It was only that I wasn't unable to find out that all points were
> software components and the map was written with this idea in mind (and
> I repeat it can be changed or we can work on a feature map).
Okay, it wasn't entirely clear that this is dealing with software
components, but I can at least *imagine* abstractions within software
for many of the points listed in the concepts mail. It's quite likely
that for some 'feature points' this cannot be translated 1 on 1 into a
software component. 'Security' is a good example, which could mean
anything from HTTPS support to support in the storage for encrypting
data, impacting very different software components. Important to notice
though is that it does impact software components, and thus should be
something on our radar.
I shall see whether I can do somekind of 'software component' extraction
from the list of concepts I posted and also see how they tie in to other
components.
>> By assuming we're thinking about a cloud of services that may or may
>> not be built anytime soon, we can avoid discussions about what's
>> "core" or not, and focus on making some of this stuff happen. Right
>> now, a big map of what's involved is nice, even if we're not going to
>> build a large part of it any time soon, as it helps us think about
>> where we are and where we're going.
>>
> Yes, of course. If you can extend the map, you're welcome, I just
> didn't see were to put some point because I wasn't able to find how
> some points can be turned into components (like content editor) from
> the software point of view.
Well, a content editor *is* a component in my view. :) It just probably
isn't running on the server-side, though it may very well need support
on the server side. For Silva, our forms editor is a software component
running entirely on the server side. Kupu is a software component
running in large part on the client side, but needs support on the
server, in case of Silva, XML <-> HTML transformation services dedicated
to Kupu. There's also the whole question about a framework for plugging
in different content editors. An example of such a framework is External
Editor in Zope 2.
Thanks for the explanations. I think it's a bit clearer to me now what
this map is about. The translation from feature into software component
is not visible on the map itself, as only the software components are
visible. Therefore a step in the thinking that produced this map was
invisible, which is somewhat confusing at first.
Regards,
Martijn
Hosting: Nuxeo: Zope service provider