Meeting minutes 12/21/1999

Topic:     ICU Development Team Meeting
Date:      12/21/1999
Time:      10:00AM - 11:00AM PST
Place:     IBM Corp.
Host:        Helena Shih(hshih@us.ibm.com)
             IBM Corp.

Attendees:
  Mark Davis (IBM)                         medavis2@us.ibm.com
  Helena Shih (IBM)                        hshih@us.ibm.com
  Tex Texin (Progress)                     texin@progress.com  
  Vladimir Weinstein (IBM)                 vweinste@us.ibm.com
  Laura Werner (IBM)                       lwerner@us.ibm.com

Minutes Takers:
  Helena Shih

- Agenda for today's meeting
- Action items from today's meeting
- Next meeting schedule

#Agenda for today's meeting#

     - Action item review from the previous meetings
     - Future meeting schedule
     - Action items from this meeting

Recap of the action items from previous Meetings:

Current PMC members are,

    Mark Davis
    Hideki Hiura
    Helena Shih [alternate: Markus Scherer]
    Tex Texin [alternate: Steve Watt]
    Bob Verbrugge [alternate: Jesper Larsen (Jesper_Larsen@nl.compuware.com)]
    Laura Werner

Action item status:
      [r] : removed
      [-] : completed
      [ ] : open

[ ] T08301999-02 [Tom and Alan] :    Contact each other regarding
transliteration framework issues.
[ ] T10251999-06 [All] :             All the ICU development team members
should subscribe to the ICU mailing lists.
[ ] T10251999-07 [All] :             Send prioritization comments to
Helena.
[ ] T11081999-02 [Laura]          Finalize the name issue with IBM
marketing.
[ ] T11081999-04 [PMC members]    Find an alternate for each member of the
PMC.
[ ] T11081999-06 [All]            Examine the API change process and submit
change suggestions to Helena.
[ ] T11231999-01 [Helena]         Go over the current APIs and mark draft
and stable.
[ ] T11231999-03 [PMC members]    ICU testing issues.
[ ] T12091999-01 [Helena]         Go over the current APIs and figure out
which ones needs to enabled for UTF-8 processing.

2. API List Review
People will start reviewing the API list sent out and let Helena know if any changes is required.  In addition, the OS abstraction proposal sent out by Bob is enclosed in this email.

#Action Items from This Meeting#

[-] T12211999-01 [Helena]         Resend Bob's proposal for OS abstraction layer.

#Next Meeting Schedule#

The next ICU meeting will be held on 1/11/1999 from 9AM-10AM PST, 12PM-1PM
EST.  The call-in number and pass code will be provided at least 24 hour
prior to the meeting.

----------------------------------
To:	icu-core@www10.software.ibm.com
cc:	 
Subject:	OS specific functionality in ICU




All,

Following is a proposal to add the ability to ICU to let users specify
their own OS functionality in a more flexible way. This is not a complete
design, but is intended to serve as a basis for discussion for adding
this functionality. Let's discuss further the next team-meeting and/or
on the core list.

Thanks,
Bob.
--

Runtime configurable OS interface.
==================================

Purpose:
Give ICU users the ability to plug-in their own OS specific functionality
at run-time.

Reason:
Users, certainly when running in a multiple OS environment, will already
have their own OS functionality implemented. In the current ICU
implementation users can plug-in their own OS functionality at compile time
by reimplementing header files, for example cmemory.h for dynamic memory
allocation. Missing in this interface is the ability to use a OS context which
is passed to every OS function. Having such a context provides the user with a
far more flexible interface. Now for example for memory allocation only
functions can be used with confirm exactly to the Unix style malloc interface.

Implementation:
1. all OS functions should have a user context (void *) as the first parameter
2. a function should be provided that allows the user to
 a) specify the user context to be passed by ICU to OS functions
 b) override the default ICU OS implementation

Some rules / restrictions should of course apply:

1. The override default ICU OS functionality function should be called before
   any other ICU function is called (a kind of init / open ICU library)
2. Complete modules should be replaced, for example for memory allocation
   either non or all of icu_alloc, icu_realloc and icu_free should be provided
   by the user.
3. When the user does 1) not use the 'override' function or 2) does not supply
   his own functions for a module, the default ICU implementation for 1) all or
   2) the non specified module, will be used.


Example geared towards dynamic memory allocation:

Function (macro) interface:
now: void *icu_alloc(size_t size)
     void *icu_realloc(void *buffer, size_t size)
     void  icu_free(void *buffer)

new: typedef void *(*icu_alloc)(void *context, size_t size)
     typedef void *(*icu_realloc)(void *context, void *buffer, size_t size)
     typedef void  (*icu_free)(void *context, void *buffer)

     typedef struct icu_OSfuncs
     {
        void        *OScontext;

        /* dynamic memory allocation */
        icu_alloc    OSalloc;
        icu_realloc  OSrealloc;
        icu_free     OSfree;

        ... other OS modules ...

     }  icu_OSfuncs;

     void icu_OSplugin(icu_OSfuncs*);

     usage:

     void *myAlloc(void *, size_t);
     void *myRealloc(void *, void *, size_t);
     void *myFree(void *, void *);

     struct icu_OSfuncs myOSfuncs;
     struct myOSContext myOSContext;

     ... init myOSContext ...

     myOSfuncs.OScontext = (void *)&myOSContext;

     /* NULLP means no user OS function */
     myOSfuncs.OSalloc   = myAlloc;
     myOSfuncs.OSrealloc = myRealloc;
     myOSfuncs.OSfree    = myFree;

     icu_OSplugin(&myOSfuncs);

     .....