Menu
▾
▴
bodington-developers
|
From: Peter C. <Pet...@me...> - 2006-06-06 13:55:17
|
> From: Selwyn Lloyd > did the idea of a common schema for an abstraction layer get aired? >=20 > we figured that a common core gives us more ways to integrate=20 > different=20 > developemnt models, i.e. spring, struts, portlets, web services and=20 > other models can sit side by side if we had a common storage model > for a core e-learning schema Intuitively this feels even harder to standardise than common interchange formats, and feels like standardisation at the wrong level to boot. People expect interchange formats to be lossy, and there can be more than one of them for a given area. By contrast, multiple storage models are beggars to integrate. What would you propose to standardise? How would you propose to let developers innovate in the presence of a common core (or is one of the goals to put a lid on unwanted innovation)? Would you expect a table-based or hierarchical storage model? - Peter |
|
From: Selwyn L. <sel...@ph...> - 2006-06-06 16:29:43
|
sorry, the question was... did the topic get aired?
still I'll try and deal with your concern about innovation and explain
our perspective a little more with some kind of illustration in text :)
*innovation
putting a lid on innovation would be the last thing on our mind [please
be assured of that]
on the contrary a common core data structure provides a license to
innovate sensibly.
regards application innovation you can have as many application
databases as you like, common is just that 'common'.
*common core
the proposal is so that a concept such as Tetra has a core on which to
build,
in this integrated model
user application [presentation layer]
components & services layer
application data layer
common data layer
or in a little more detail
my integrated portal thingy me bob [bod 2]
|
bod tetra | sakai tetra | ioportal tetra
| | |
bod_db sakai_db ioportal_db
| | |
|
common core
*schema
If I was going to propose a common core to begin with then it might be
based on LDAP / Enterprise hybrid but I'm not proposing the schema, just
asking if the topic was aired.
perhaps the LDAP schema is to generic for us and we need to extend that
to cope with other common considerations in e-learning.
but common core all about calling a spade a spade and reuseability.
Cheers
Sel
Peter Crowther wrote:
>>From: Selwyn Lloyd
>>did the idea of a common schema for an abstraction layer get aired?
>>
>>we figured that a common core gives us more ways to integrate
>>different
>>developemnt models, i.e. spring, struts, portlets, web services and
>>other models can sit side by side if we had a common storage model
>>for a core e-learning schema
>>
>>
>
>Intuitively this feels even harder to standardise than common
>interchange formats, and feels like standardisation at the wrong level
>to boot. People expect interchange formats to be lossy, and there can
>be more than one of them for a given area. By contrast, multiple
>storage models are beggars to integrate.
>
>What would you propose to standardise? How would you propose to let
>developers innovate in the presence of a common core (or is one of the
>goals to put a lid on unwanted innovation)? Would you expect a
>table-based or hierarchical storage model?
>
> - Peter
>
>
>_______________________________________________
>Bodington-developers mailing list
>Bod...@li...
>https://lists.sourceforge.net/lists/listinfo/bodington-developers
>
>
>
>
--
Selwyn Lloyd
Phosphorix
tel: 07979240124
irc://irc.ionode.org
channel: #ionode
web: http://www.phosphorix.co.uk
forum: http://forum.ionetwork.ac.uk
|
|
From: Alistair Y. <ali...@sm...> - 2006-06-06 17:06:57
|
Could you expand on what common core means Selwyn? Perhaps I'm way off on a tangent here but you mentioned LDAP as a core schema. The federated services world started along this route (eduPerson) but seem to be migrating away from it and leaving schema design to application developers, using the OID model. Do you mean, e.g. Tetra can see "user_id" in bod_db and know it's the sam= e as "userid" in sakai_db? That would be a semantic nightmare unless OIDs were used. We could define a Tetra OID space. Plug in a new application with it's own db, have it provide an OID layer for it and hey presto, "Tetra" can AAA users across applications: - User logs in to Sakai - User clicks on link to login to Bod questionnare (say) - Bod is shibbed so "Tetra" kicks in - "Tetra" says to Sakai - give me OIDs 1.45.5.3 and 9.4.21.4 - Something makes a decision based on the values of those attributes defined by those OIDs. Sounding like a XACML layer in there too! I only mention it as the concepts sound a wee bit the same. --=20 Alistair Young Senior Software Engineer UHI@Sabhal M=F2r Ostaig Isle of Skye Scotland > sorry, the question was... did the topic get aired? > > still I'll try and deal with your concern about innovation and explain > our perspective a little more with some kind of illustration in text :) > > > *innovation > > putting a lid on innovation would be the last thing on our mind [please > be assured of that] > on the contrary a common core data structure provides a license to > innovate sensibly. > regards application innovation you can have as many application > databases as you like, common is just that 'common'. > > *common core > > the proposal is so that a concept such as Tetra has a core on which to > build, > > in this integrated model > > user application [presentation layer] > components & services layer > application data layer > common data layer > > or in a little more detail > > > my integrated portal thingy me bob [bod 2] > | > bod tetra | sakai tetra | ioportal tetra > | | | > bod_db sakai_db ioportal_db > | | | > | > common core > > *schema > If I was going to propose a common core to begin with then it might be > based on LDAP / Enterprise hybrid but I'm not proposing the schema, jus= t > asking if the topic was aired. > perhaps the LDAP schema is to generic for us and we need to extend that > to cope with other common considerations in e-learning. > but common core all about calling a spade a spade and reuseability. > > Cheers > > Sel > > > > > > > > Peter Crowther wrote: > >>>From: Selwyn Lloyd >>>did the idea of a common schema for an abstraction layer get aired? >>> >>>we figured that a common core gives us more ways to integrate >>>different >>>developemnt models, i.e. spring, struts, portlets, web services and >>>other models can sit side by side if we had a common storage model >>>for a core e-learning schema >>> >>> >> >>Intuitively this feels even harder to standardise than common >>interchange formats, and feels like standardisation at the wrong level >>to boot. People expect interchange formats to be lossy, and there can >>be more than one of them for a given area. By contrast, multiple >>storage models are beggars to integrate. >> >>What would you propose to standardise? How would you propose to let >>developers innovate in the presence of a common core (or is one of the >>goals to put a lid on unwanted innovation)? Would you expect a >>table-based or hierarchical storage model? >> >> - Peter >> >> >>_______________________________________________ >>Bodington-developers mailing list >>Bod...@li... >>https://lists.sourceforge.net/lists/listinfo/bodington-developers >> >> >> >> > > -- > Selwyn Lloyd > Phosphorix > tel: 07979240124 > irc://irc.ionode.org > channel: #ionode > web: http://www.phosphorix.co.uk > forum: http://forum.ionetwork.ac.uk > > > > _______________________________________________ > Bodington-developers mailing list > Bod...@li... > https://lists.sourceforge.net/lists/listinfo/bodington-developers > |
|
From: Selwyn L. <sel...@ph...> - 2006-06-06 17:59:18
|
hi Alistair yeah LDAP is just an example in terms of 'common' vocab for things we could share across integrated apps I think the first point I'm trying to raise is perhaps OSS communities in e-learning might agree one common layer to bind applications together. Our business case is for quickly resuable tools within a service application, such as a PLE, VLE or other learner centric ecclectic service. Meaning you can quickly integrate our tools into your application and vice versa. So while I'm not 100% sure what OID's are... wrt to unique ID's we use GUIDS to pair between non related apps and distinct insitutions so we store collections of instituion ID plus applications user unique ID pairs against a interoperability GUID.... the idea is to to integrate more tools within another application here though and less identities across services... so yes with this model, our collective 'future tetra based tools' share a common person id method, or as 'de niro' put it so aptly in meet the fockers our tools are in [the circle of trust] :) Sel Alistair Young wrote: >Could you expand on what common core means Selwyn? Perhaps I'm way off on >a tangent here but you mentioned LDAP as a core schema. The federated >services world started along this route (eduPerson) but seem to be >migrating away from it and leaving schema design to application >developers, using the OID model. > >Do you mean, e.g. Tetra can see "user_id" in bod_db and know it's the same >as "userid" in sakai_db? That would be a semantic nightmare unless OIDs >were used. We could define a Tetra OID space. > >Plug in a new application with it's own db, have it provide an OID layer >for it and hey presto, "Tetra" can AAA users across applications: > >- User logs in to Sakai >- User clicks on link to login to Bod questionnare (say) >- Bod is shibbed so "Tetra" kicks in >- "Tetra" says to Sakai - give me OIDs 1.45.5.3 and 9.4.21.4 >- Something makes a decision based on the values of those attributes >defined by those OIDs. > >Sounding like a XACML layer in there too! > >I only mention it as the concepts sound a wee bit the same. > > > -- Selwyn Lloyd Phosphorix tel: 07979240124 irc://irc.ionode.org channel: #ionode web: http://www.phosphorix.co.uk forum: http://forum.ionetwork.ac.uk |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X