hpoj-devel

Re: [hpoj-devel] some port of PML to ptal

[<pa...@rc...>]

Jarl Friis wrote:
> I have ported some of the PML stuff to the ptal API.
> 
> until now I have ported getValue and setvalue, they are not thoroughly
> tested, but I can get the LCD lines at least :-) porting xojpanel..???
Hi, Jarl.  I've actually done a lot of this work already (adding PML
support to PTAL).  I'm using a different design from ojlib, so I started
from scratch rather than porting ojlib code, just as I did with PTAL itself.

> I was considering if it were best placed in ptal-mlc.c or maybe even
> a new ptal-mlc-pml.c, currenctly its a mix of pml.c and ptal.c
My overall philosophy for PTAL, which I continued when adding PML support,
is to have the generic interface and common implementation in ptal.c,
MLC-specific implementation in ptal-mlc.c, and JetDirect-specific
implementation in ptal-hpjd.c.  That way, the differences in accessing
PC- and JetDirect-connected peripherals are hidden from applications which
use PTAL.

> I do not have the time to continue the development in January, but I might
> do something in February, hope the code is good for soemthing, at least
> inspiration :-)
I got distracted from this lately dealing with I/O and printing issues in
preparation for releasing 0.7, and I'll try to get back to it within the
next couple of weeks.

> There are some open question:
> 1)What are the TWO bytes in the begining of PML values of type String?
The symbol set (character set) identifier.

> 2)How are the THREE bytes of errorcode (after the exec_code byte) supposed
> to be interpreted when such are sent as a reply?
According to the PML spec (which you can get by registering for a free
membership at http://www.hp-developer-solutions.com), these three bytes are:
0x18 (ErrorCodeDataType)
0x01 (constant)
0x?? (ErrorValue, for example 0x83=ErrorUnknownObjectIdentifier)

> Does anyone know anything about the PML error codes that can turnup in
> request responses?
> Has it anything to do with the ones found on HP help page:
> http://www.hp.com/cposupport/multifunction/support_doc/bpu50364.html
Those are firmware assert (panic) codes which indicate serious hardware
failures or firmware bugs and are completely unrelated to the error codes
defined by the PML protocol.

> I am currently working on adding the PML to the ptal, and I discovered
> that the PML oids on the web are not the same as in the
> ojlib/pmloidentries.c the difference are (at least) the two folloing
> objects:
I plan to significantly rewrite the web-based documentation once I finish
obsoleting ojlib and (if everything goes well) ieee12844*.c.  In addition,
I want to avoid coding knowledge of specific OIDs at the PTAL level, so
the centralized OID table will either go away or move somewhere else in
the codebase.

(BTW, it's not necessary for people to CC me on messages they send to the
mailing list.  I CC myself when sending messages just to make sure I have
a copy of it in case it gets lost or delayed.)

David

Re: [hpoj-devel] some port of PML to ptal

[<pa...@rc...>]

Jarl Friis wrote:
> I thought when there is no sign of this in the cvs, it was a
> job to be done, anyway I got a deep knowledge of MLC, PML, so I will
> eventually be able contribute on something else.
Sorry about that.  I will make it clearer on the web what the status is
of in-progress items, but actually I had already said "in progress" for
the item "Add PML support to PTAL" on the TODO page.

> But I still wonder why the CVS is on the release-0.7 stage... is it only
> used for realeases? not development?
I prefer not to commit new developments to CVS until they are fairly
functional.  That makes it easier to make interim releases (as was the case
with 0.7) without having to "back out" file revisions or set up branches.

> Are you working full-time on hpoj?
No, but I'd like to.  :-)  For now I'm mostly working on it in my spare time
since I have other responsibilities at work, but out of necessity some of it
does end up spilling into company time.

> Good idea, the OID tables are device dependent, different devices
> recongnise different OIDs, correct?, so there should probably be one
> OID-table for each device or devicegroup, it would be smart if one could
> autodetect what kind of device, and then use the related table for that,
> the one on the web/in the pmloidentries.c is for OfficeJets I guess.
There actually is a fair amount of consistency in the most important OIDs,
but there are also some device-specific OIDs which may not be worth worrying
about for our purposes.

David

[hpoj-devel] OID lists

[Jarl F. <ja...@di...>]

On Sun, 31 Dec 2000, David Paschal wrote:

> Jarl Friis wrote:
> > Good idea, the OID tables are device dependent, different devices
> > recongnise different OIDs, correct?, so there should probably be one
> > OID-table for each device or devicegroup, it would be smart if one could
> > autodetect what kind of device, and then use the related table for that,
> > the one on the web/in the pmloidentries.c is for OfficeJets I guess.
> There actually is a fair amount of consistency in the most important OIDs,
> but there are also some device-specific OIDs which may not be worth worrying
> about for our purposes.

I can imagine the usage of one OID is the same among different devices,
but what I ment was: the *set* of OIDs is not the same among different
devices, right? hence the OID-table is device dependent. So it would
probably be in order to make a global table of all known OIDs, and then
for each device make a table (representing a subset of the global
list) that tells which OIDs the device can use. the device-specific subset
could eventually just be a list of indexes to the global table.

Jarl

Re: [hpoj-devel] some port of PML to ptal

[Jarl F. <ja...@di...>]

On Sun, 31 Dec 2000, David Paschal wrote:

> Jarl Friis wrote:
> > I have ported some of the PML stuff to the ptal API.
> > 
> > until now I have ported getValue and setvalue, they are not thoroughly
> > tested, but I can get the LCD lines at least :-) porting xojpanel..???
> Hi, Jarl.  I've actually done a lot of this work already (adding PML
> support to PTAL).  I'm using a different design from ojlib, so I started
> from scratch rather than porting ojlib code, just as I did with PTAL itself.

I thought when there is no sign of this in the cvs, it was a
job to be done, anyway I got a deep knowledge of MLC, PML, so I will
eventually be able contribute on something else.

But I still wonder why the CVS is on the release-0.7 stage... is it only
used for realeases? not development?

> > I do not have the time to continue the development in January, but I might
> > do something in February, hope the code is good for soemthing, at least
> > inspiration :-)
> I got distracted from this lately dealing with I/O and printing issues in
> preparation for releasing 0.7, and I'll try to get back to it within the
> next couple of weeks.

Are you working full-time on hpoj?

> 
> > 2)How are the THREE bytes of errorcode (after the exec_code byte) supposed
> > to be interpreted when such are sent as a reply?
> According to the PML spec (which you can get by registering for a free
> membership at http://www.hp-developer-solutions.com), these three bytes are:

Thanks, that helped a lot.

> > I am currently working on adding the PML to the ptal, and I discovered
> > that the PML oids on the web are not the same as in the
> > ojlib/pmloidentries.c the difference are (at least) the two folloing
> > objects:
> I plan to significantly rewrite the web-based documentation once I finish
> obsoleting ojlib and (if everything goes well) ieee12844*.c.  In addition,
> I want to avoid coding knowledge of specific OIDs at the PTAL level, so
> the centralized OID table will either go away or move somewhere else in
> the codebase.

Good idea, the OID tables are device dependent, different devices
recongnise different OIDs, correct?, so there should probably be one
OID-table for each device or devicegroup, it would be smart if one could
autodetect what kind of device, and then use the related table for that,
the one on the web/in the pmloidentries.c is for OfficeJets I guess.

Jarl