Re: [interfacekit] Re: Back home
"Ingo Weinhold" <bonefish-CFLBMwTPW48UNGrzBIF7/[email protected]>
| Newsgroups | gmane.os.openbeos.storage |
|---|---|
| Message-ID | <5339013865-BeMail@graete> |
> > "Ingo Weinhold" <bonefish-CFLBMwTPW48UNGrzBIF7/[email protected]> wrote: > > OBOS and a working app server, I've pretty much nothing else to do. > > So > > let's start the discussion. We may want to move it to the SK team > > list > > ([email protected]) which will be happy so see some > > traffic > > after quite some time. :-) > > And another mailing list I am subscribed to ;-) Hehe, quite inflationary, isn't it. But don't worry, this one is very low traffic -- I guess, the last mail has been sent three months or so ago. :-) > You can either use this mail to start a discussion, or if nothing > happens, I will dig into it and present what I think about the > private > Device, Session, Partition API. I don't think, I will have enough time to delve deeper into it today, and thus quite likely not before tuesday. So feel free to start. > BTW there are several apps there using it (like DiskProbe, > DriveSetup, > ..) Not too surprising at least. ;-) BTW, I wonder which degree of compatibility we need to maintain. Binary, source, or not even that? Before OT, noone outside of Be Inc. should have even known about that API and the OT header is ornamented with the usual `your app will break, if you use this API' warning. And as we need to write our own DiskProbe and DriveSetup anyway, it wouldn't hurt at all, when the R5 versions break. However, not going with binary compatibility means, that a separate OT binary needs to be compiled for OBOS (the B.E.OS guys have the same problem, of course). Dropping source compatibility even requires to branch OT (being no problem with the OT maintainer in the boat, though :-)). Just some thoughts... CU, Ingo