[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [board-agenda] Kavi "Delta" document and executive summary
Hi Eduardo.
Good points on formatting. The reason we haven't delved deeper into how
or whether to prioritize workarounds is that the Board asked us for a
"Delta document" - differences between what Kavi 5 offers today, and the
functionality we have from our customized Kavi. We (staff) took it upon
ourselves to suggest workarounds but how those are implemented will
largely depend on available resources. I trust that, with our document
in hand, the Board and the OASIS community will give us a clear way
forward.
I should also say, however, that we are working on an outsourced
solution where said workarounds and even possibly access to Kavi 5 APIs
(if, in fact these exist, but we are told they do...) will be handled by
a third party - a company that works closely with Kavi and carries out
this sort of assignment. I'm sure the details will sharpen as we get
closer to the Board meeting.
Drupal does not go out the window; on the contrary, it's already being
used by staff to update portions of content; moreover, we're told our
new public pages in the Kavi 5 scheme would in fact be developed using
Drupal and dovetail with what we already have.
More on this during the Board meeting: please stay tuned.
Thanks again.
Laurent
On 7/21/2010 4:48 PM, Eduardo Gutentag wrote:
> I think most people must be seeing red by now ;-)
>
> Laurent, could you clarify something? Seems to me that there is a
> difference between red rows where there is a possible workaround and red
> rows where there appear to be no possible workaround (see rows 27 and 28
> for respective examples of this); wouldn't it make sense to use
> different colors to make this more obvious? For instance, I think that
> there is a big difference between not being able to display committees
> by category or by name, on the one hand, which would be bad enough, and
> not being able to keep a count of whether a member has reached
> participation obligation or not, which would be, I think, quite worse.
> Is the lack of differentiation an indication that although there is no
> current workaround known there may be one in the future? Or is this an
> indication that no prioritization (if that is the right word) has been
> done on this yet?
>
> Another question: How would this affect the work of Drupalization that
> Carol and Jose have been doing over the past few years. Out the window?
>
> And finally: some of the non-red rows have potential workarounds, but
> there is no indication of the extent of work that would have to be
> invested on each of them and whether it would be a one time effort or a
> continuing maintenance issue. Are you planning on making that kind of
> determination soon?
>
> Thanks!
>
>
> On 07/21/2010 09:50 AM, Laurent M Liscia wrote:
>> [Resending to the broader Agenda list]
>>
>> Preamble: We are considering migrating our data to Kavi 5; and have
>> produced the attached spreadsheet to highlight the difference between
>> what we have currently on our custom OASIS version of Kavi, maintained
>> by us, and what is available on Kavi 5.
>>
>> Executive Summary (to help navigate the spreadsheet)
>>
>> To adequately assess the impact of migration to a Kavi-hosted solution
>> it is necessary to distinguish between two classes of OASIS
>> applications.
>>
>> 1. Kavi apps
>>
>> Kavi apps support TC "workspace" activities and membership functions.
>> In the current system this corresponds to things under
>> www.oasis-open.org/apps/... and www.oasis-open.org/members/...
>>
>> 2. OASIS apps
>>
>> OASIS apps are, essentially, everything else related to
>> www.oasis-open.org. Internally these are often referred to as "www"
>> ("dub-dub-dub") apps. For example (non-exhaustive):
>>
>> http://www.oasis-open.org/home/index.php
>> http://www.oasis-open.org/who/
>> http://www.oasis-open.org/join/
>> http://www.oasis-open.org/specs/ (approved standards)
>> http://tools.oasis-open.org/ (Wikis, SubVersion repositories)
>> Member Sections, e.g. http://www.oasis-blue.org/
>> Public email archives (http://lists.oasis-open.org/archives/)
>>
>> Currently, both classes of application are hosted in-house by OASIS
>> and are driven by a common, local data backend (MySQL database, email
>> directories) and therefore tightly coupled.
>>
>> Kavi corp will host only Kavi TC workspace apps. This means that
>> OASIS must continue to host (or contract with someone other than Kavi
>> corp to host) the www.oasis-open.org domain (and associated
>> (sub)domains) in order to support OASIS www apps and to map URIs
>> such that the existing self-hosted Kavi app URIs continue to resolve
>> correctly post-migration.
>>
>> Backend data required to support Kavi apps is owned by Kavi and is not
>> accessible to external non-Kavi applications. Should the OASIS Kavi
>> apps migrate to a Kavi corp hosted solution, the database goes with
>> them and is no longer available to OASIS www apps that need it.
>> This requires that OASIS www apps be decoupled from the Kavi app
>> database.
>>
>>
>> A detailed list of the deltas resulting from a Kavi 5 migration in
>> spreadsheet form is attached (note that spreadsheet line items
>> highlighted in red indicate deltas that arise specifically when OASIS
>> www apps no longer have access to data in the kavi 5 database). A
>> summary of the deltas is provided immediately below.
>>
>>
>> OASIS www content
>>
>> Various content served up by the OASIS www apps is generated
>> dynamically using data queried from the Kavi database. Should the
>> Kavi apps migrate to a Kavi hosted solution, that data would no longer
>> be available. This dynamically generated content would either have to
>> be converted to manually maintained static web pages or the database
>> would need to be manually mirrored and maintained by OASIS staff.
>>
>> Affected content includes but is not limited to:
>>
>> Public TC home pages e.g. OASIS look and feel, list committees by
>> category, IPR pages, obligation counter …
>>
>> Member sections: membership lists, member section Committee lists
>>
>>
>> Membership-based Access Control
>>
>> Not all features of OASIS www apps are available to the general
>> public. For instance, certain operations on TC Wikis and
>> Subversion repositories are available only to TC members acting in
>> certain roles. The OASIS tools applications implement this level of
>> access control "seamlessly" today by reading TC membership and role
>> data in the shared backend database.
>>
>> Should the Kavi apps migrate to a Kavi hosted solution, the data
>> regarding TC membership and roles goes with it and would no longer be
>> available to OASIS tools. Maintaining the appearance of seamlessness
>> would require OASIS staff to manually mirror and maintain TC
>> membership and role data in the Kavi database and make it accessible
>> to the OASIS tools applications.
>>
>> As of this writing 52 TC Wikis and 18 TC SVN repositories would be
>> affected by this.
>>
>> The ability to restrict access to certain email archives (e.g. Board
>> of Directors) is similarly affected.
>>
>> Access control for the OASIS STV ballot application is affected as well.
>>
>> Public Email Archives
>>
>> From http://lists.oasis-open.org/archives/:
>>
>> "OASIS hosts a wide variety of mailing lists to enable collaborative
>> work among members, facilitate public input, and communicate with the
>> global community. In support of its commitment to information access
>> as a foundational principle in open standards development, OASIS
>> provides archives for all mailing lists, the majority of which are
>> viewable by the public. The OASIS mailing list archives may be
>> searched using either MarkMail or Google."
>>
>> OASIS mailing list apps and the Kavi email functions are driven from
>> a common email data repository. Should the Kavi apps migrate to a Kavi
>> hosted solution, that repository would no longer be available to the
>> OASIS mailing list apps.
>>
>>
>>
>> ---------------------------------------------------------------------
>> This list is for posting purposes only. Any discussion of agenda items
>> should be held on theboard-comment@lists.oasis-open.org list. Thank you.
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:board-agenda-unsubscribe@lists.oasis-open.org
>> For additional commands, e-mail:board-agenda-help@lists.oasis-open.org
>
> --
> Oracle <http://www.oracle.com>
> Eduardo Gutentag | Director, Standards Strategy & Policy
> Phone: +1 510 550 4616 <tel:+1%20510%20550%204616> | Fax: +1 510 550
> 4616 <fax:+1%20510%20550%0A4616> | SMS: +1 510 681 6540
> <tel:+1%20510%20681%206540>
> Oracle Corporate Architecture Group
> 5op334, 500 Oracle Parkway, | Redwood Shores, California 94065
> Green Oracle <http://www.oracle.com/commitment> Oracle is committed to
> developing practices and products that help protect the environment
--
Laurent Liscia, Executive Director
OASIS: Advancing open standards for the information society
1-978-667-5115, extension 201
Take a tour of OASIS at:
http://www.oasis-open.org/home/tour.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]